Benchmarks

#Overview

These measurements first answer two questions: how much of the CSS a documentation page delivers matches that page, and how much CSS the same UI generates with Master CSS and with Tailwind CSS. A technical appendix covers build time, Chromium's response to CSS volume and the cost of each Master CSS rendering mode. Check each section's conditions and limits before applying a result to another application.

The snapshots were recorded on November 4, 2026 on one machine (Apple M5 Max, macOS) with Chromium 156. Master CSS packages were built from revision add10eec6. The browser lifecycle snapshots come from 3fc239c6c, recorded earlier that day; add10eec6 changes the compiler and the static build hosts, not the runtime, the preset or the engine. The Master CSS documentation pages were measured from the production build of the same checkout; the other documentation sites were fetched from their public pages on the same day.

#Documentation page CSS

Question answered: how large are the inline style bodies and linked stylesheets discovered from each documentation page’s initial HTML, and how many of their style rules match that page?

RawBrotli

Raw

Master CSSMaster CSS 0.8 kB + Other inline 1.0 kB + External CSS 108.6 kB

110.4 kB

Angular1.4× Master CSS

151.8 kB

Vue.js1.7× Master CSS

186.3 kB

Material UI2.5× Master CSS

277.4 kB

Bootstrap2.7× Master CSS

293.9 kB

Next.js4.3× Master CSS

479.9 kB

Tailwind CSS6.0× Master CSS

657.7 kB

Both views use the same scale and the committed page snapshot.

The chart sums the inline style bodies and linked stylesheets of each site’s listed page; each body is compressed independently for the Brotli view. A single page can misrepresent a site, so the table adds four more documentation pages per site and reports the range.

The Master CSS documentation pages combine two kinds of CSS. The per-page style#master-css body holds the utilities the page uses; on the listed page it is under 1 kB. The linked stylesheets hold the site’s design system components, the preset base and the tokens they reference; they make up most of the bytes. Each linked stylesheet belongs to a component and arrives whole, so pages that use more components link more files and the total varies from page to page. A page that renders only part of a component, such as the closed search dialog or a few of the article components, still receives all of that component’s rules; that is where most of its unmatched rules come from. Several of the other sites deliver the same stylesheet on every page.

Matched rules measure how precisely a page’s CSS fits that page, independently of its size. A rule counts when its selector, without state pseudo-classes and pseudo-elements, matches an element after load; rules for other viewports, color schemes or later interactions count as unmatched only when their element is absent. The share is a property of each site’s own stylesheets, not of the CSS framework alone.

Limits: these are collected CSS body sizes, not browser transfer or timing measurements. The collector does not follow CSS import graphs or count JavaScript-injected styles. Compression of complete responses, cache reuse, headers, CDN behavior, fonts, images and application runtime work are outside the comparison. Each site’s CSS also reflects its own design and build choices, so this sample does not isolate the cost of a CSS framework; the static fixtures below compare frameworks on the same UI.

#Same UI, generated CSS

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

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; production command timing is in the technical appendix.

#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.

Every measured setup writes one CSS file. A Master CSS static build inlines the stylesheets its entry imports, the preset included, so a page receives the generated CSS in one request, as it does from Tailwind CSS. A stylesheet that keeps an external import, a namespace or a qualified import of a file with its own imports stays a separate file; none of the fixtures has one.

Limits: these numbers do not measure browser parsing, style recalculation, layout, paint, interaction cost, watch mode, or HMR. The fixtures use utility classes only; the page CSS sample shows how much authored component CSS can add.

#Changes since the July snapshots

The previous snapshots, dated July 1, 2026, measured a revision whose engine has since moved to Rust and whose class syntax has since changed. To separate code changes from the machine, the browser and the benchmark harness, the July revision cd5a3972a was rebuilt and its own benchmark runner run again on the same machine and Chromium build as the current measurements. Production builds alternated between the two checkouts three times, so background load on the machine affected both sides alike.

That rerun reproduced the July static CSS output byte for byte, so the earlier figures were valid for their revision. The current fixtures express the same rendered values in the current class syntax; every class in them generates CSS, and the CLI's --strict mode accepts them.

On this machine, the current revision starts the browser runtime faster and hydrates progressive pages with less data, while downloading a larger runtime and taking longer for a cold production command. Generated CSS for the docs fixture grew by about 5% and, as in July, arrives as one file. Each checkout installs its own Tailwind CSS and Vite versions, so the Tailwind CSS controls reflect those upgrades as well as run-to-run noise.

Interaction readiness is about the same for every mode, including Tailwind CSS, on both revisions. It is bounded by the harness's frame waits rather than by Master CSS work, so readings move in steps of about one frame (17 ms); the lower Tailwind CSS reading on the July revision is one such step.

#Technical appendix

These suites explain the costs behind the results above: production commands, Chromium's response to CSS volume, and what each Master CSS rendering mode sends and does in the browser. Read them when choosing a rendering mode or diagnosing build time.

#Core hypothesis

The delivery question is whether the browser work saved by loading fewer CSS rules can offset the cost of generating rules at runtime. Compare the whole page lifecycle: initial loading, later interactions and long-session cleanup.

Runtime and progressive rendering add JavaScript work to generate rules from observed classes. When that class set is smaller than a static source-derived set, they can reduce initial CSS and CSSOM rule volume. Whether that reduction offsets startup and mutation work depends on the workload. 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. Read the measurements in this order when evaluating that delivery tradeoff:

1. Page CSS and static CSS output show how many bytes, files, selectors, declarations, and rules a page or 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.

Check correctness alongside timing: a smaller or faster result is useful only if the fixture renders the intended UI. The tables include computed-style and progressive-adoption checks where the suite records them.

#Production build

Question answered: how long does a complete cold or repeated production command take for each static fixture and setup?

Interpretation: build timings include process, CLI or Vite, and package startup for each command path, so a small fixture mostly measures fixed startup cost. Repeat production build means a second command in the same workspace; it is not 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: module imports and source scanning take a few milliseconds of an ordinary fixture command. Registering the stylesheet entry and composing the output take tens of milliseconds each, and a repeated compose on the same setup still costs about three fifths of the first. A CPU profile of one CLI run (node --cpu-prof) attributes the largest share of the command, about a third, to compiling the imported preset stylesheet graph, work that does not depend on the fixture’s classes; small fixtures therefore pay nearly the same fixed cost as larger ones.

Limits: diagnostic probes measure separate envelopes and substeps. Do not add their timings together as if they were a single production trace.

#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, program 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.

The payload chart counts the complete HTML response and each external asset requested during the initial load once. Inline CSS and the injected hydration manifest are already inside that HTML, so they are not separate segments. Empty asset fields do not add compression-container bytes to the total.

These totals are estimates from the recorded asset fields, not measured network transfer sizes. They exclude headers and transport overhead, and every page’s HTML includes the benchmark harness scripts. The detailed table retains separately compressed inline CSS and hydration fragments as diagnostics; adding those columns to the response total would count their content twice.

Interpretation: runtime mode delivers no generated CSS but fetches the browser runtime and its compiled default program before the page is styled. Progressive mode begins with server/build-time CSS in the HTML and adopts it with the runtime; it fetches the program only when a class is missing from the hydration data, which did not happen during these initial loads.

Limits: these numbers measure initial local fixture loads only. Post-load mutation belongs to the interaction suite. Master static and Tailwind static load one CLI-generated stylesheet each, built from equivalent fixture intent, not identical class strings. Runtime and progressive pages load the self-contained global runtime bundle; a bundler integration can load a smaller progressive entry, measured by the runtime size contract. See Rendering modes for how each mode starts.

#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. Readiness includes the harness’s frame waits and is nearly identical across modes, so compare runtime mutation work and style recalculation for the cost a mode adds. The rule delta counts rules in the runtime’s public snapshot. While a progressive page defers its engine, that snapshot holds no rules; the first class missing from the hydration data starts the engine, which adopts the server-rendered rules into its state, so that interaction’s delta also counts the adopted rules. Compare runtime mutation work and style recalculation for its CSSOM cost.

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

#Browser lifecycle and long sessions

Question answered: how much rendering and runtime work accumulated during each recorded five-minute session?

The lifecycle suite compares Master CSS static, runtime and progressive setups with a Tailwind CSS static control. The charts below select the five-minute long-session scenario. Each mode has one measured run; a median with one sample is that single observation, not evidence of repeatability.

The table’s elapsed time covers the entire scripted session and its final settling frames. The source metric is named inp-style-interaction-ms, but for this scenario it is approximately five minutes by construction. It does not measure an individual input delay or Web Vitals INP.

Interpretation: compare total style recalculation with the runtime mutation work each mode adds. A single run per mode cannot establish a stable speedup. Compare repeated runs on the same machine before drawing conclusions about layout, paint, responsiveness or overall performance.

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.

#Data sources

The charts read committed snapshots under benchmarks/**/snapshot.json and benchmarks/browser-lifecycle/long-session-evidence.json, dated November 4, 2026. Fixtures, metric families, publication rules, recorded commands and validation steps are in the benchmarks README. Reproducing a result requires the matching source revision and lockfile, not just a current package installation.