Benchmarks

Read reproducible Master CSS benchmarks for the runtime/CSSOM tradeoff: small runtime, fewer CSS rules, browser cost, and lifecycle behavior.

Overview

Benchmarks make Master CSS output, build, delivery, browser, and interaction costs inspectable. They are scoped evidence, not universal guarantees for every application.

This page collects the public benchmark snapshots used to explain Master CSS performance tradeoffs. Each result stays tied to the fixture, command, package versions, browser, machine, sample count, and limits that produced it.

Core hypothesis

The central performance question is not whether a runtime is faster than no runtime in isolation. It is whether small Runtime plus very few CSS rules can produce lower whole-browser cost than zero Runtime plus many CSS rules over the page lifecycle.

For Master CSS, runtime and progressive rendering trade a small amount of JavaScript work for lower delivered CSS, smaller CSSOM/rule volume, and fewer rules for the browser to consider during style recalculation. Tailwind CSS is useful here as a zero-runtime static CSS control: it does not provide a runtime-equivalent implementation, but it does represent the large static CSS side of the tradeoff.

The current evidence should be read as directional. It can support the hypothesis in measured fixtures when runtime/progressive modes reduce CSSOM/rule volume and style recalculation enough to offset runtime bootstrap, observe, and mutation work. It does not establish that every application will be faster.

Selector matching is not directly measured as a stable Chromium metric in these suites. It is inferred from delivered selectors, CSSOM rule count, runtime-generated rule count, and trace-derived style recalculation.

How to read these results

Benchmarks are useful when they answer a narrow question. This page builds the runtime/CSSOM hypothesis in a validation ladder:

1. Static CSS output and structure show how many bytes, selectors, declarations, and rules each static setup delivers.
2. Browser CSS cost calibrates how Chromium responds when CSS rule volume grows while DOM is fixed.
3. Delivery modes show what Master static, runtime, progressive, and Tailwind static send and do on initial load.
4. Interaction cost measures post-load DOM and class changes, including runtime rule work.
5. Browser lifecycle evidence combines long-session browser work, CSSOM/rule volume, and runtime instrumentation.

Read each chart as evidence for the measured fixture and command, then compare it with the complete table and committed snapshot before applying the result to another app.

Tailwind CSS is not a runtime-equivalent comparison. In runtime-oriented suites, it is the static browser-control baseline for the zero-runtime, larger-static-CSS side of the hypothesis.

Lower numbers are not automatically better in every context. A smaller CSS artifact can shift work into runtime, a faster cold command can hide less useful output, and a local Chromium trace does not replace real production telemetry.

Before publishing or acting on a number, the fixture must first pass correctness checks: rendered output should match the intended UI, computed-style assertions should pass, generated output should be attributable to the fixture, and missing-rule checks should fail loudly.

No benchmark result is permission to change CSS output, cascade order, hydration behavior, runtime behavior, extraction behavior, or public APIs. If a result exposes a real hot path, the fix still needs the owning package tests and compatibility review.

Current results

Page CSS size

Question answered: how much inline and external CSS do popular documentation pages transfer in the initial HTML response?

This snapshot counts inline style tags and external stylesheets discovered from each page's initial HTML. Master CSS stays near 6 kB brotli on this documentation site because progressive rendering emits the page rules first, then lets runtime rendering handle later dynamic classes.

Limits: this is a page transfer measurement, not a browser timing metric. Browser cache state, CDN behavior, JavaScript-loaded styles, fonts, images, and application runtime work are outside the snapshot.

Static CSS output, structure, and production build

Question answered: how do equivalent static Master CSS and Tailwind CSS v4 fixtures compare for generated CSS bytes, CSS AST structure, and full production command timing?

The curated snapshot combines css-output-size, build-performance, and css-structure results. The headline charts use the docs fixture and CLI variants so the first view stays focused on static artifact output.

Representative fixture

The docs fixture represents a dense article and documentation layout with navigation, code blocks, and tables.

Complete data

The complete tables keep every measured fixture and both CLI/Vite setup variants.

Interpretation: CSS structure metrics explain why byte counts differ before browser-cost claims are introduced. Tailwind CSS and Master CSS fixtures target equivalent rendered UI intent, not identical class strings.

Limits: these numbers do not measure browser parsing, style recalculation, layout, paint, interaction cost, watch mode, or HMR.

Build path diagnostics

Question answered: which Master CSS startup, integration, extraction, and compiler substeps explain full command cost?

This snapshot combines startup-diagnostics, build-diagnostics, compiler-diagnostics, and extraction-diagnostics. It explains the Master CSS build path; it is not a cross-framework production benchmark.

Interpretation: ordinary fixture command cost is currently dominated by cold process/module startup and integration startup overhead, while normal-fixture compiler and extraction medians are smaller.

Limits: diagnostic probes explain envelopes and substeps. They do not justify changing generated CSS, cascade order, extraction correctness, runtime behavior, or public APIs.

Browser CSS cost

Question answered: how does CSS rule volume affect Chromium style recalculation, layout, and paint when DOM is fixed, and how does DOM scaling behave when CSS is fixed?

This suite uses local fixture pages, deterministic external CSS, Playwright, and Chromium tracing. It is a browser-only calibration suite, not a Master CSS versus Tailwind CSS comparison.

Interpretation: the CSS volume curve is the main input for judging how much upfront CSS a delivery mode asks Chromium to load before interaction. The DOM scaling control helps separate DOM, style, and layout scaling from CSS payload size.

Limits: these numbers do not measure runtime rule generation, real application JavaScript, Firefox, WebKit, CDN behavior, or public real-world page variance. Chromium trace event names can change across browser versions.

Master CSS delivery modes

Question answered: what initial payload, local Chromium load cost, runtime bootstrap cost, manifest loading, and progressive adoption behavior does each delivery mode produce?

The suite compares Master CSS static, runtime, progressive, and Tailwind CSS static browser-control variants across the static fixture set.

Representative fixture

The primary charts show the docs fixture.

Interpretation: progressive begins with server/build-time CSS in the HTML and adds a runtime handoff. Runtime mode starts smaller on CSS output but pays browser runtime and manifest costs when classes are discovered in the DOM.

Limits: these numbers measure initial local fixture loads only. Post-load mutation belongs to the interaction suite. Master static and Tailwind static use CLI-generated CSS from equivalent fixture intent, not identical class strings.

Interaction cost

Question answered: how expensive are post-load class toggles, first-time runtime rule generation, DOM append/remove, theme switches, viewport resize, and cleanup cycles?

The suite measures local Chromium interactions across dynamic, dashboard, and stress-dom fixtures. Tailwind CSS static variants act as browser controls for style/layout/paint work; they do not have a client-side runtime rule-generation equivalent.

Interpretation: runtime and progressive modes should be read in two layers: user-visible mutation readiness, then runtime stylesheet work. Existing-rule toggles, first-time class generation, DOM changes, and cleanup cycles answer different performance questions.

Limits: these numbers do not measure route transitions, HMR, dev workflow, CDN behavior, Firefox, WebKit, or public real-world application variance.

Browser lifecycle and INP-style interactions

Question answered: can small runtime/progressive work plus low CSSOM/rule volume lower whole-browser lifecycle cost compared with zero-runtime static CSS?

The suite is the closest current test of the core hypothesis. It keeps Tailwind CSS as the zero-runtime static browser-control setup and compares it with Master CSS static, runtime, and progressive setups across lifecycle scenarios. The latency value is an INP-style local fixture measurement, not real Web Vitals INP.

Interpretation: current five-minute local Chromium evidence directionally supports the hypothesis for style recalculation: Master runtime and progressive show lower style recalculation medians than the Tailwind static browser control while carrying measured runtime mutation work. Layout, paint, long-task, and INP-style latency medians remain measured data, not wins, because they do not establish the same directional advantage.

Limits: selector matching time remains an inference from CSSOM/rule volume plus style recalculation unless Chromium exposes a stable trace metric for it. CSSOM memory and GC pressure are reported only when the collection method is stable enough to reproduce on the same browser version.

Methodology and limits

Fixture matrix

Fixture-based suites compare equivalent UI output, not identical class strings.

Each fixture should publish source markup, Master CSS setup, Tailwind CSS setup when relevant, generated outputs, and exact commands.

Metric families

Browser timings should be measured with fixed viewport, device scale, browser version, warmup rounds, measured rounds, and separated cold/warm cache modes when cache state changes interpretation.

Delivery modes

Runtime and progressive rendering optimize what CSS is delivered up front. They do not make browser style calculation free: when an interaction creates many first-time utility rules, the browser still needs to account for those new stylesheet rules before it can paint the updated DOM.

Tailwind CSS comparisons

Tailwind CSS comparisons use pinned Tailwind CSS v4 tooling and official entrypoints for static output, production build, and static browser-control measurements.

Runtime-equivalent claims should be avoided because Tailwind CSS does not perform the same client-side class observation work as Master CSS runtime rendering. In the runtime/CSSOM hypothesis, Tailwind CSS represents the zero-runtime static baseline, not a runtime competitor.

Publication rules

Curated snapshots are committed; raw reports are not. Raw reports, traces, diagnostics, screenshots, downloaded history, and temporary workspaces stay under benchmarks/.results/**.

Every public result should include the fixture, adapter or mode, package versions, command, machine, operating system, browser version when relevant, viewport/device scale, warmup rounds, measured rounds, cache mode, sample count, and known limits.

Allowed public claim language is intentionally narrow: use "directional evidence," "supports the hypothesis in this fixture," and "static browser-control baseline." Avoid "proves," "overall faster," and "runtime wins" unless future same-machine repeat evidence passes an explicit direction and threshold gate for the named metric.

Real Web Vitals and Lighthouse scores are outside the current benchmark source. The benchmark suite prefers direct output, build, trace, and interaction measurements that can be tied back to a specific fixture and command.

Data sources

Curated snapshots are committed under benchmarks/**/snapshot.json and benchmarks/browser-lifecycle/long-session-evidence.json.

Lifecycle publication checks are pnpm --filter ./benchmarks check:browser-lifecycle, node benchmarks/browser-lifecycle/check-readiness.mjs --profile long-session-evidence browser-lifecycle/long-session-evidence.json, and node benchmarks/browser-lifecycle/compare-stability.mjs after same-machine repeat reports.