Benchmarks

Compare Master CSS output size, page CSS delivery, and build characteristics with reproducible benchmark fixtures.

Overview

Benchmarks make Master CSS output and delivery costs inspectable. They are useful for understanding tradeoffs, but they are not universal guarantees for every application.

This page is the public benchmark roadmap and results index for Master CSS. Current results stay close to their methodology, and planned work is listed here before it becomes a measured claim.

Benchmark roadmap

The benchmark target is reproducible comparison, not a single universal score. Each result should include the fixture, command, package versions, machine/browser, sample count, and known limits.

Benchmark guardrails

Benchmarks on this page are advisory. They are meant to make tradeoffs inspectable, not to promise the same result for every application, browser, machine, CDN, or framework integration.

Before a performance or size number becomes a public result, the fixture must first pass correctness checks: rendered output should match the intended UI, computed styles should cover critical assertions, generated output should be attributable to the fixture, and missing-rule checks should fail loudly.

Every published result should include package versions, command, fixture, adapter, machine, operating system, browser version when relevant, warmup and measured rounds, cache mode, viewport/device scale, and known limits. Cold-cache and warm-cache runs should be separated whenever cache behavior changes the interpretation.

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

Current evidence and remaining gap

The current benchmark set already answers the first part of the browser-rendering question. Static comparison snapshots record generated rule, selector, declaration, layer, at-rule, and byte counts. The browser CSS cost suite separately isolates a fixed DOM while deterministic external CSS grows from small to xlarge rule volumes, then records Chromium style recalculation, layout, and paint.

The delivery-mode and interaction suites add the Master CSS runtime side of the question. They measure HTML, CSS, runtime JavaScript, manifest payloads, runtime bootstrap, observe/hydrate time, runtime generated rule count, style raw bytes, post-load class toggles, new-rule generation, DOM append/remove, theme switching, viewport resize, and cleanup cycles. Tailwind CSS remains a static browser-control variant in those suites, not a runtime-equivalent comparison.

Internal runtime diagnostics have also localized one important interaction hotspot: cleanup-cycle cost was dominated by browser style invalidation from runtime stylesheet changes and retained generated stylesheet volume, while MutationObserver delivery and ensureClassRules/deleteClassRules instrumentation were measurable but not the primary cost in that diagnostic run.

The remaining public gap is lifecycle evidence. The browser lifecycle suite now has a committed internal snapshot refreshed from a 2026-06-30 review-grade all-scenario baseline, but this page should not yet claim that runtime rendering produces better real-user interaction performance overall. Segmented five-minute long-session evidence now has committed curated evidence across Master static, runtime, progressive, and Tailwind static browser-control modes; public conclusions still require repeated review and presentation.

Current result: Page CSS size

The current page CSS size benchmark compares the CSS transferred by several official documentation sites. It counts both inline style tags and external stylesheets discovered in the initial HTML response.

Master CSS keeps this documentation site's page CSS around 6 kB with brotli compression because progressive rendering emits only the rules required by the page. The Master CSS segment is the generated style#master-css; Other inline covers non-Master inline style tags; External CSS covers linked stylesheets.

The page CSS size snapshot is generated from benchmarks/docs-page-css-size. It fetches each documentation page, parses the initial HTML, follows link[rel*="stylesheet"], and records raw and brotli-compressed byte counts.

Current result: Static CSS output, structure, and production build

The current Tailwind CSS comparison uses equivalent static fixtures for Master CSS and Tailwind CSS v4. It reports generated CSS artifact size, AST-derived CSS structure metrics, and full production command elapsed time for CLI and Vite setups.

Snapshot summary

This curated snapshot is generated from css-output-size, build-performance, and css-structure on Apple M3 Max with Node v24.15.0. View the committed snapshot data.

Representative fixture

The primary charts show the docs fixture so the visual comparison stays focused. This fixture represents a dense article and documentation layout with navigation, code blocks, and tables.

The primary charts compare Master CSS and Tailwind CSS using CLI output so the headline view stays focused on static artifact output. CLI setup means Master CSS static CLI versus Tailwind CSS CLI. Vite setup data remains available in the expanded detail tables.

Brotli CSS output

Master CSS versus Tailwind CSS compressed output for the docs fixture. Lower is smaller generated CSS, not browser style cost.

Cold production command

Master CSS versus Tailwind CSS full production command timing for the docs fixture. Lower is faster and this is not watch mode.

CSS structure

Master CSS versus Tailwind CSS declaration counts for the docs fixture. These AST-derived metrics are structure signals, not browser style-calculation timings.

Complete data tables

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

CSS bytes

Raw, gzip, and brotli byte counts for each generated CSS artifact.

Production build

Median elapsed time for cold and repeat production commands.

CSS structure table

Rule, selector, declaration, at-rule, layer, and selector-shape counts parsed from generated CSS artifacts.

These numbers do not measure browser parsing, style recalculation, layout, paint, interaction cost, watch mode, or HMR. CSS structure metrics explain generated output shape; they are not browser timing metrics. Tailwind CSS and Master CSS fixtures target equivalent rendered UI intent, not identical class strings.

Current result: Browser CSS cost

The browser CSS cost benchmark 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.

Snapshot summary

This curated snapshot is generated from browser-css-cost. It keeps the CSS and DOM axes separate so later delivery-mode results can explain whether a cost comes from upfront rule volume, DOM size, or runtime work.

CSS rule volume

The primary curve keeps visible DOM fixed and varies deterministic external CSS rule volume. The charts show warm-cache median Chromium trace timings for style recalculation, layout, and paint.

DOM scaling control

The secondary control keeps CSS fixed and increases repeated DOM items. This helps separate DOM, style, and layout scaling from CSS payload size.

Browser cost data table

The complete table includes cold-cache and warm-cache variants for both axes.

These numbers do not measure runtime rule generation, interaction mutation cost, HMR, real application JavaScript, Firefox, WebKit, CDN behavior, or public real-world page variance. Chromium trace event names can change across browser versions, so browser-cost conclusions should be read with the fixture source, package versions, browser version, sample count, and committed snapshot data.

Current result: Master CSS delivery modes

The Master CSS delivery modes benchmark compares initial payload, local Chromium load cost, runtime bootstrap, manifest loading, and progressive adoption across Master CSS static, runtime, progressive, and Tailwind CSS static variants.

Snapshot summary

This curated snapshot is generated from master-delivery-modes. It uses the static fixture set and reports local Chromium medians beside payload bytes and delivered CSS structure.

Representative fixture

The primary charts show the docs fixture so the visual comparison stays focused on a dense article and documentation layout.

Initial payload

Payload composition includes HTML, external CSS, inline CSS, runtime JavaScript, manifest JSON, and progressive hydration manifest bytes. Values use brotli compression.

Browser load

Load timing charts show local Chromium medians for navigation-ready, style recalculation, layout, and paint.

Runtime bootstrap

Runtime bootstrap and observe timings apply to Master runtime and progressive modes.

Complete data table

The full table keeps every measured fixture and delivery mode for verification.

These numbers measure initial local fixture loads only. They do not measure post-load mutation, route transitions, HMR, dev workflow, Vite injection cost, CDN behavior, Firefox, WebKit, or public real-world page variance. Master static and Tailwind static use CLI-generated CSS from equivalent rendered fixture intent, not identical class strings.

Current result: Interaction cost

The interaction cost benchmark measures post-load user-facing changes in local Chromium: class toggles, runtime rule generation, DOM append/remove, theme switches, viewport resize, and repeated mutation cleanup.

Snapshot summary

This curated snapshot is generated from interaction-cost. It uses dynamic, dashboard, and stress-dom fixtures across supported Master CSS static, runtime, progressive, and Tailwind CSS static variants.

Representative fixture

The primary charts show the dynamic fixture because it covers class toggles, new-rule generation, DOM mutation, and cleanup-cycle behavior.

Mutation readiness

Mutation-ready timing is measured from the interaction start until the page completes the post-mutation settle frame and correctness assertions.

Runtime update cost

Runtime update charts isolate Master runtime/progressive stylesheet work during interaction scenarios.

Complete data table

The full table keeps every supported fixture, mode, and scenario combination for verification.

These numbers measure local Chromium post-load fixture interactions only. They do not measure route transitions, HMR, dev workflow, CDN behavior, Firefox, WebKit, or public real-world application variance. Tailwind CSS static variants are browser controls for style/layout/paint work; they do not have a client-side runtime rule-generation equivalent.

Fixture matrix

Future fixture-based suites should use equivalent UI output rather than identical class strings.

Each fixture should publish source markup, Master CSS setup, Tailwind CSS setup, generated outputs, and the exact commands used to produce results.

Metrics

Browser timings should be measured with fixed viewport, device scale, browser version, warmup rounds, and measured rounds. Chromium tracing is the primary public path for browser-cost metrics. These numbers are advisory because browser scheduling, hardware, memory pressure, and cache state affect them.

CSS structure metrics are published beside byte size and production build timing. They explain how generated byte differences relate to rule count, selector count, declaration count, at-rule shape, layer distribution, and selector complexity before browser-cost claims are introduced.

Master CSS delivery modes

Progressive begins with server/build-time CSS in the HTML and adds a runtime handoff, so its benchmark needs both first-response payload metrics and post-hydration mutation metrics.

The delivery-mode suite measures initial payload, local Chromium page load, runtime bootstrap, manifest loading, and progressive style adoption across Master CSS static, runtime, progressive, and Tailwind CSS static variants. It does not measure post-load mutation; those interaction costs stay in the next suite.

Tailwind CSS comparisons

Tailwind CSS comparisons should use pinned Tailwind CSS v4 tooling and official entrypoints:

• @tailwindcss/cli for command-line builds.
• @tailwindcss/vite for Vite build comparisons.
• Tailwind source detection behavior from Detecting classes in source files.

The available Tailwind CSS suites compare static outputs and production build behavior. Runtime claims should be avoided unless the benchmark is explicitly measuring browser CSS cost from static CSS output, because Tailwind CSS does not perform the same client-side class observation work as Master CSS runtime rendering.

Tailwind CSS and Master CSS fixtures should render equivalent UI, but they do not need identical class strings. Setup labels should be explicit: recommended/default setup and utility-only setup are separate results if both are measured. Dynamic-class fixtures should document extraction limits and capability differences separately from raw benchmark wins.

Browser CSS cost

Large CSS can affect the browser even when no JavaScript framework is involved. The browser-cost suite keeps the CSS and DOM axes separate so later delivery-mode comparisons can explain whether a result came from upfront rule volume, DOM size, or runtime work.

Primary: CSS rule volume

The primary calibration keeps visible DOM fixed and varies deterministic external CSS rule volume:

• small-css, medium-css, large-css, and xlarge-css external stylesheets.
• A fixed repeated DOM item count for every CSS volume level.
• Raw, gzip, and brotli CSS bytes for each volume level.
• Rule, selector, and declaration counts parsed from the generated CSS.
• Initial stylesheet attachment and parse cost.
• Style recalculation, layout, and paint while the visible DOM stays fixed.
• Long tasks where Chromium exposes stable trace data.

This curve is the main input for judging how much upfront CSS a delivery mode asks the browser to load before interaction.

Secondary: DOM scaling control

The stress-dom control stays in the suite, but it answers a different question. It keeps CSS fixed and varies DOM volume:

• small-dom, medium-dom, and large-dom repeated item counts.
• Measured DOM node count after the page reaches the benchmark-ready marker.
• The same fixed CSS bytes and CSS structure metadata for each DOM scale.
• Style recalculation, layout, paint, navigation-ready time, and long tasks while CSS volume stays fixed.

This control is useful for interpreting runtime scan, mutation, route transition, and layout sensitivity later. It is not the main input for comparing CSS delivery modes because delivery modes primarily change when and how many CSS rules are loaded or generated.

This suite uses local fixture pages, Playwright, and browser tracing with fixed viewport, fixed device scale, and disabled unrelated network variance. It reports medians plus raw samples as ignored artifacts, with cold-cache and warm-cache results separated when cache state affects the measurement.

Interaction cost

The interaction-cost suite measures changes users can feel:

• Toggle state classes on many elements.
• Toggle classes that are already represented in CSS versus classes that require new rule generation.
• Insert and remove repeated components.
• Switch light/dark or theme mode.
• Resize viewport and container-query layouts.
• Repeat mutation cycles to catch cleanup and memory issues.

For Master CSS runtime and progressive modes, the suite reports both DOM work and runtime stylesheet work. For static Tailwind CSS output, the comparable measurement is the browser's style/layout/paint cost after the DOM or class change.

The internal runtime mutation diagnostics suite narrows the cleanup-cycle hotspot to dynamic and stress-dom fixtures in Master runtime and progressive modes. It records MutationObserver delivery counts, ensureClassRules/deleteClassRules call shape, temporary class cleanup, retained rule state, and Chromium trace timings so optimization work can target the confirmed source of cost.

Browser lifecycle suite

The internal browser lifecycle suite tests the lifecycle version of the runtime tradeoff: does a small amount of runtime work buy enough reduction in generated CSS rules to lower style recalculation, selector matching proxies, and user-visible interaction latency over time?

This suite should keep Tailwind CSS as a static browser-control setup and Master CSS as static, runtime, and progressive setups. It should publish only measured comparisons that share equivalent rendered UI intent and should keep "INP" labels reserved for measurements that match the platform metric closely enough; otherwise use INP-style interaction latency.

A curated internal snapshot is generated from the all-scenario browser-lifecycle baseline and has been refreshed from the 2026-06-30 review-grade run. Committed five-minute long-session evidence also covers Master static, runtime, progressive, and Tailwind static browser-control modes. A same-machine repeat review has passed coverage, correctness, sample-count, and long-session duration gates, but the suite remains internal until the deltas have final claim and narrative review; the current data should be used for benchmark validation rather than public performance claims.

Internal evidence: Browser lifecycle

This internal evidence summarizes the committed all-scenario snapshot and the committed five-minute segmented long-session evidence. It is not an Available benchmark result, and the latency value remains INP-style interaction latency rather than real Web Vitals INP.

The five-minute evidence keeps Tailwind CSS as a static browser-control mode. It shows local fixture medians for browser work and runtime instrumentation, while selector matching remains an inference from CSSOM/rule volume plus style recalculation.

Lifecycle scenarios

Lifecycle limits

Selector matching time should remain an inference unless Chromium exposes a stable trace metric for it. CSSOM memory and GC pressure should be reported only when the collection method is stable enough to reproduce on the same browser version. Lifecycle reports should keep raw traces internal and publish curated snapshots only after repeated same-machine runs.

Implementation phases

Future normalized reports should stay internal to the benchmark workspace unless they become a documented public data format. A report should include schemaVersion, suite, generatedAt, environment, packages, fixtures, variants, metrics, samples, summary, limits, and artifacts.

Methodology and limits

Use the raw numbers to inspect source size and the brotli numbers to approximate compressed transfer size. Browser cache state, CDN behavior, JavaScript-loaded styles, fonts, images, and application runtime work are outside the page CSS size snapshot.

Fixture-based benchmark results should be compared on the same machine, with the same package versions, the same browser version, and the same sample settings. Raw benchmark history should stay ignored; only curated snapshots should be committed and rendered publicly.

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