Layout benchmark results

Phase mapping used in the report:

• Layout only: Taffy compute_layout ≈ Blitz layout ≈ Servo Fragment Tree Construction; Chrome Layout and Ladybird layout are listed too but include text shaping (see below), so on text-bearing cases they are only comparable with each other.
• Box construction + layout: Blitz construct + layout ≈ Servo Box Tree + Fragment Tree ≈ Chrome rebuildLayoutTree + Layout (Chrome builds LayoutObjects inside UpdateLayoutTree, not Layout) ≈ Ladybird construct + layout ≈ Firefox Reflow ≈ WebKit layout (WebKit, like Firefox, builds its render tree while resolving style, so layout is the whole box pass). Firefox's frame construction happens inside the Styles flush with no marker of its own, so Reflow under-counts this table by the frame-construction time (small: it is a tree walk with no shaping) and Styles over-counts the Style table by the same amount.
• Text shaping sits in different phases: Blitz shapes when it builds the Parley inline layout in construct (build_inline_layout_into, run as the deferred pconstruct tasks), Servo in Box Tree Construction (inline/shaping_queue.rs::shape_batch → font.shape_text while building each inline formatting context), whereas Chrome (NGInlineNode::PrepareLayout → HarfBuzz inside Layout), WebKit (inline layout measures runs through FontCascade::width, which shapes), Firefox (nsTextFrame::Reflow → EnsureTextRun → gfxFont::ShapeText) and Ladybird (inline_level_iterator.rs::shape_glyph_data → shape_text during inline layout) shape lazily while laying out. Shaping dominates construction on text-heavy pages (Blitz Wikipedia: construct 60 ms vs layout 20 ms), so "Box construction + layout" is the like-for-like table for any case with text; "Layout only" is like-for-like only among Taffy, Blitz and Servo (the text/ cases have no Taffy tree).
• Style: Blitz style ≈ Servo Styling ≈ Chrome recalcStyle; Firefox Styles and WebKit style are listed here too but, like Chrome's UpdateLayoutTree, they include frame / render-tree construction; Ladybird style is update_style().
• Whole pipeline (style to laid-out tree): Blitz resolve() ≈ Servo restyle_and_build_trees (Styling + Box Tree + Fragment Tree, plus stylist preparation and damage computation) ≈ Chrome UpdateLayoutTree + Layout ≈ Firefox Styles + Reflow ≈ WebKit style + layout ≈ Ladybird update_layout(). None of these includes display-list or paint work: Blitz's resolve() ends with build_paint_tree (the stacking-context / paint-order lists, ~0.3 ms on Wikipedia; scene generation in blitz_paint::paint_scene is outside the timed interval), Servo's stacking-context tree is built by the enclosing handle_reflow (recorded as reflow, not shown in the table; ~9 ms on Wikipedia), and the measured reflows build no display list.

out/servo-threads.md is a layout_threads = 1/3/4/6/8 sweep of Servo on seven cases (servoN is accepted as an engine id by bench for any N; only servo1/servo are in the main run).

Servo's restyle_and_build_trees and handle_reflow include work the children spans do not (stylist preparation, damage computation); the report shows them separately.

Blitz feature cost

blitz-dom's floats and writing-mode are opt-in and the runner enables both (apps/browser ships with floats). What they cost, as callgrind instructions in resolve_layout for one layout of the page (deterministic; the layout hashes are identical across the four builds on all 43 pages):

writing-mode is paid on every style read (the frame-transposing getters in stylo_taffy), floats in block layout with inline content; so the Blitz columns measured with both are ~10% above what a build without them would show on these pages.

Firefox reports the longest Reflow and Styles marker of the page's content process. The reveal flush is one Styles + one Reflow; the page also records a few sub-0.1 ms reflows (the initial display:none document, a nested flush after the reveal), so verify prints the reflow count and the sum of all reflows relative to the longest. The Styles marker's elementsTraversed is the styled-element count (styled= in verify, nodes + html/body/#cb).

1. "Whole pipeline" endpoints are close but not identical

Every whole-pipeline column ends at the laid-out tree and excludes display-list and paint work: Chrome UpdateLayoutTree + Layout (before PrePaint/Paint), Firefox Styles + Reflow (before its display list), Ladybird update_layout() (committed layout tree), Servo restyle_and_build_trees (stylist flush, damage walk, Styling + Box Tree + Fragment Tree; the enclosing handle_reflow, recorded as reflow and not tabulated, adds the stacking-context tree, ~9 ms on Wikipedia — the measured layout-query reflows never build a display list), Blitz resolve(). What each still carries beyond style + construction + layout is the grey "rest" segment of the stacked bars: Blitz's build_paint_tree (stacking-context / paint-order lists, ~0.3 ms on Wikipedia) plus transforms and damage cleanup; Servo's stylist preparation and damage computation; Chrome's non-style, non-construction part of UpdateLayoutTree. Blitz's scene generation (paint_scene) is not inside the timed interval and Servo's display list is not built by the measured reflows, so no engine's figure includes drawing-command generation; the one asymmetry left is that Blitz's paint-order tree is inside its figure and Servo's stacking-context tree is outside its.

Sources: reported intervals, Blitz's resolve implementation, and Ladybird instrumentation.

2. Equal-work validation is incomplete

Known failures still receive timings and can win rows. The clearest exclusion is Servo's pangui/percentage_and_ratio: it renders empty. Its timing should be N/A, not eligible to win a row.

Other cases need qualification:

• flex/absolute/10000 has substantially different geometry.
• flex/wide/10000 reports 3,505 box-size mismatches, a maximum difference of 735,072 px, yet 0% viewport pixel difference for Blitz versus Chrome. Whether this is a dump/correspondence bug or a layout difference, it is unresolved verification evidence, not proof of equal work.
• Servo's text check sees only the first 800 pixels: "7/7 background bands equal" does not establish equivalence across 1,000 paragraphs.
• Ladybird's flex/huge_nested/* root sizes differ substantially from Chrome's, and some text paragraphs wrap differently. Matching node counts alone does not establish matching layout work.

The original verification snapshot lacked Firefox even though it appeared in the timing tables. **That coverage gap was resolved by dbbdbce**, which adds Firefox and Ladybird to the committed verification table. This does not resolve the geometry and viewport-coverage limitations above.

Small rasterisation differences are not themselves disqualifying. Missing layout features, different wrapping, or skipped content are. Validation should cover offscreen geometry and text line counts, not just viewport pixels or root sizes. Exclude known unequal-work engine/case pairs from rankings, and investigate unexplained mismatches before treating them as equivalent.

Frozen real pages

The [real-pages work reviewed at 0f0d306](https://github.com/nicoburns/browser-layout-bench/blob/0f0d306/README.md) adds useful coverage, but is not equal-work evidence: it documents unsupported floats and other layout differences. For example, on the frozen Wikipedia page 460 of 866 sampled Blitz boxes differ in size from Chrome's by more than 1px. Knowing the cause explains the mismatch; it does not make the workloads equivalent.

These pages are simplified snapshots: scripts are removed, fonts are replaced, images become placeholders, and some CSS and controls are rewritten. They test the resulting frozen documents, not the original live sites.

3. Minimum-of-nine hides significant instability

For Blitz's text/paragraphs/1000 resolve time, the saved samples have:

That is far beyond a 1–3% variation. A minimum can legitimately estimate best-case latency, but it is not typical performance, and ratios of independently selected minima can be unstable. The spread alone does not identify its cause.

The benchmark-development session assembled the dataset through several --merge runs: Chrome was rerun separately, and Firefox/parallel-construction variants were added later. Consequently, the final cross-engine comparisons do not all benefit from contemporaneous interleaving, even though each individual invocation supports it.

Report median plus spread, retain minimum as a secondary statistic, and rerun the final engine set together on an idle machine. Record the run configuration and provenance so later subset updates remain identifiable.

Sources: raw samples, aggregation and merge logic, and documented protocol.

4. Cache state and CPU allocation are not matched

• Taffy: reuses its tree, explicitly warms up twice, then dirties nodes.
• Blitz: fresh document, but several iterations within one process; mimalloc as the global allocator (with glibc, allocator work and page faults were ~37% of the layout phase on the 100k-node cases).
• Chrome: fresh pages within one browser launch.
• Servo/Firefox: one process per round, a fresh window/tab per iteration after a discarded warm-up load of the case (Servo over WebDriver, Firefox via Playwright; all Firefox tabs in one content process).
• Ladybird: one WebDriver --headless browser per round, a fresh window (and WebContent process) per iteration, the UI process's font service warm, a warm-up load only for the real pages.

Excluding startup time does not eliminate differences in allocator, font, thread-pool, and other process-local caches. This is neither a consistently cold nor consistently warmed protocol. Choose and document a common lifecycle, or report cold and warmed cases separately.

CPU placement is a configuration choice: the 2026-10-23 dataset pinned the single-threaded runners (--cpus) while the current one runs everything unpinned on 8 vCPUs, so Servo(1) vs Servo(3) is a thread-count comparison and Blitz vs blitz-par a 1-thread vs pool comparison on the same cores. Servo's layout_threads sizes only the style pool used for styling and the full box-tree build and layout; the incremental try_layout pass of the relayout steps runs its par_iters on rayon's global pool (all 8 vCPUs here) in Servo(3), and layout_threads=1 also disables Servo's block-level layout cache (SequentialLayoutState), so Servo(1) relayout is a different code path, not just fewer threads. Those are valid configuration comparisons, but not controlled equal-resource comparisons. Separate single-threaded layout/style and default-parallelism results, with affinity and worker counts stated explicitly.

Sources: Taffy runner, Blitz runner, browser runners, and Ladybird runner.

5. Instrumentation and corpus scope limit the conclusions

The Servo tracing fix was important: the documented example fell from 31 ms to 2.3 ms after removing per-item spans. But tracing overhead has not been equivalently calibrated across all engines. Chrome still enables broad blink/timeline categories; Blitz's outer resolve() timer even includes printing its phase log. Small differences deserve particular caution. Calibrate instrumentation overhead rather than assuming it is equal or negligible.

Direct Taffy also uses a different revision and, by default, omits the browser's containing-block wrapper. It is an algorithm baseline, not a browser score or a clean measure of Blitz's integration overhead.

Finally, the synthetic corpus and frozen, simplified real pages measure specific initial-layout workloads, not general browsing, incremental layout, JavaScript, or time-to-paint.

Sources: Servo tracing filter, versions and methodology, Taffy's optional wrapper, and Blitz's outer timer.

6. Text shaping is in construction for Blitz/Servo but in layout for Chrome/WebKit/Firefox/Ladybird

Blitz shapes when it builds the Parley inline layout (construct, including the deferred pconstruct tasks) and Servo during Box Tree Construction; Chrome, WebKit, Firefox and Ladybird shape text lazily while laying it out, so their layout figures include shaping, line breaking and font fallback and their construction figures (where they exist) are a tree walk. The "Layout only" table therefore compares different work on any case with text: Blitz layout and Servo Fragment Tree are post-shaping line breaking and box placement, Chrome Layout and Ladybird layout are shaping plus that. The "Box construction + layout" table contains the same work for every engine and is where Firefox's Reflow and WebKit's layout are listed (their frame / render-tree construction happens inside the style flush, with no marker of its own, so that table under-counts them by the construction time and the Style table over-counts them by the same amount; it is a tree walk with no shaping, so the amount is small relative to layout on text-heavy pages). The flex/, grid/ and most pangui/ cases have no text, so there the two tables differ only by genuine construction cost and "Layout only" is comparable across all engines.

7. Relayout scenarios measure invalidation strategy, with warm caches

The relayout steps run after the first layout in the same document, in a fixed order, each on the reverted tree, so every step sees the allocator, font and layout caches left by the previous ones (identical across engines, but not a cold relayout, and the revert's layout is not measured). The numbers compare how much work each engine's invalidation lets through as much as how fast it lays out: Blitz currently restyles the whole subtree on any inline-style change (set_attribute → RestyleHint::restyle_subtree() + full damage), so its whole-pipeline relayout figures are dominated by style even when layout is small; Servo's repair path reports no box/fragment spans, so only restyle_and_build_trees is available. Small incremental relayouts (tens of µs in Chrome) sit at the trace clocks' resolution — prefer the median there. Only elements with a box take part (getClientRects() non-empty; Blitz: not display: none/contents, nor inside display: none), and leaves are the innermost block-level elements (display: inline is excluded, replaced or not, since width on a non-replaced inline changes no geometry and Blitz gives inline elements no node layout to mutate; so on the text cases the leaves are the paragraphs, not the spans in them); the root children cloned by append are the boxed ones, so on the real pages it clones top-level sections rather than list items and can cost as much as a full layout (rustdoc). The browsers' and Blitz's selections were compared on every text and real case and the generated smoke cases: same leaf/root-child counts and deepest leaves everywhere, except where Blitz styles the page differently — real/mdn, 566 vs 558 leaves (Blitz does not apply the page's .code-example:has(…) {display: none} and lays those divs out) and real/wikipedia, 2109 vs 2107 (Blitz gives <picture> no box, so the <a> and <img> around two of them become leaves instead). Taffy's direct trees have no inline or hidden nodes. Post-mutation geometry is not yet part of verify.

gen builds the trees from Taffy's benchmark suite (wide / deep / super-deep flexbox, absolute positioning, wide / deep grids) and serialises them to HTML with inline styles, one <div> per Taffy node. Every leaf gets a distinct background colour so renders can be pixel-compared. There is no text, so text shaping and line breaking are excluded; these pages measure the layout algorithms and the surrounding style/box machinery only. The pangui/<template> cases are the PanGUI flexbox templates from Taffy's benchmark crate (gen/pangui/*.txt, taffy_benchmarks::pangui_template), translated to Taffy styles the same way as Taffy's pangui bench and serialised like the rest.

The text/ cases (paragraphs, flex_cards, inline_mixed, each at 100 and 1000 items) are hand-built HTML with deterministic prose (a fixed word list sampled with the seed), set in DejaVu Sans shipped in fonts/ (@font-face, four faces, loaded via a relative url(); licence in fonts/LICENSE-DejaVu.txt), with line-height: 20px and text-rendering: geometricPrecision (without it Chrome rounds each glyph advance to a whole pixel and breaks ~5% of lines differently). They have no Taffy tree, so Taffy direct is not measured for them; they compare Blitz (Parley) construct+layout against Servo Box+Fragment Tree and Chrome rebuildLayoutTree+Layout, i.e. shaping plus line breaking (see the phase table below for why shaping lands in the construction phases).

The root is absolutely positioned inside a #cb containing block sized to the Taffy available space (max-content becomes a 1,000,000px box). run.py gen also writes corpus/reveal/*.html for Servo and Chrome: the tree starts display:none and a trailing script reveals it and forces layout, so the whole tree is styled and laid out in a single reflow after parsing has finished. Pages with @font-face reveal the tree only after document.fonts has loaded every face, so that reflow shapes with the web font rather than a fallback. Servo loads the reveal pages over a localhost HTTP server started by run.py because its fetch rejects file:// fonts (CORS mode from an opaque origin); blitz-runner serves file:// URLs itself, synchronously, before the timed resolve().

real/: saved web pages

The real/<page> cases are seven real pages saved on 2026-10-20 and frozen by real/freeze.py (sources and licences in real/LICENSES.md; the saved originals live in real/raw/, ignored):

real/freeze.py fetch <page> saves a page with wget -p -k -E -H into real/raw/<page>/; real/freeze.py freeze <page> rewrites it into real/<page>/index.html plus the placeholder images, and real/manifest.tsv (name, directory, element count, viewports). run.py gen copies real/<page>/ into corpus/real/<page>/ and corpus/reveal/real/<page>/ and appends one manifest line per viewport (every page is currently 1280×800, as real/<page>; another width would be real/<page>@<w> via the optional 7th manifest column, which the other pages leave at the global 1280×800). Node count is the number of elements under <body>; there is no Taffy tree. The <body> itself is the #cb element (a wrapper <div> would change the containing block of fixed/absolute children and body's own margin and flex behaviour), so the reveal script restores its stylesheet display instead of forcing block, and the runners wait for display != none.

Freezing rules (all in real/freeze.py, never by hand-editing the saved HTML): scripts, inline handlers, <noscript>, <template>, <link>s (screen stylesheets are inlined first, print and dark-scheme sheets dropped), <meta http-equiv> and comments go; <img>, <picture>, <video>, <iframe>, <canvas>, <object>, <embed> and inline <svg> become <img> placeholders of the same natural size (flat grey PNGs under real/<page>/ph/, width/height attributes kept or taken from the saved file, id/class/style kept so CSS sizing resolves the same way); form controls become span.lb-input (UA control sizes differ); closed <details> keep only their <summary>. In CSS, @import, @font-face and every url() go (no background images), font-family/font are rewritten to "LB Sans" or "LB Mono" (the DejaVu faces in fonts/, via ../../fonts/), and text-rendering, scrollbar-gutter (Chrome reserved a 15px gutter on MDN, Firefox and Blitz none), transform/translate/rotate/scale (dioxuslabs.com's hidden search modal is scale: 1.1; it does not affect layout but skews getBoundingClientRect() and the screenshot) and animation declarations are stripped. The page gets html{text-rendering:geometricPrecision;font-family:"LB Sans"} and pre,code,kbd,samp,tt{font-family:"LB Mono"} at the lowest specificity so that elements left in the UA default font do not fall back to system fonts (Blitz is built without any and rendered the flexbox spec's unstyled paragraphs 0px tall). No page issues a non-file:// request (checked with Playwright request logging); file names with ? are renamed by wget's -E/-k handling and nothing is referenced with %3F.

Equal-work check (./run.py verify --engines chrome,blitz,firefox1,servo1,ladybird --filter real/, 2026-10-20; page height = document.documentElement.scrollHeight, Blitz: the <html> box's scrollable overflow, Ladybird: getBoundingClientRect() like Chrome; Servo reports neither boxes nor a root):

WebKit (./run.py verify --engines chrome,webkit --filter real/, 2026-10-24; details and the two saturated flex cases in out/webkit.md): px differing vs Chrome 6.0% / 3.6% / 1.8% / 1.6% / 1.2% / 1.0% / 1.4% in the table's order; boxes 208/866 sizes (594 positions), 4/176 (23), 0/1792 (0), 3/471 (428), 0/84 (0), 0/48 (0), 2/12 (2); page heights 84,997 / 19,788 / 155,326 / 90,170 / 5,444 / 1,232 / 1,136. WebKit uses the same 1/64 px int32 LayoutUnit as Blink and clamps flex/wide/10000 and flex/absolute/10000 at the same 33,554,432 px (8,440 / 5,800 boxes clamped vs Chrome's 8,416 / 5,729), so those two cases are not equal work for it either.

Chrome and Firefox agree on every page to within 0.3% of the page height (the pixel difference is glyph rasterisation plus a few 1px line-height roundings). Known differences, each with the CSS feature responsible (Blitz unless stated; "positions" differ wherever an earlier height does):

• float: Blitz is built with its opt-in floats feature (without it floats are laid out in flow and Wikipedia's infobox becomes a full-width block: 21.9 % of pixels, page 87,076 px). With floats the page is 83,201 px (2.2 % shorter than Chrome) and 460 of the 866 boxes still differ, mostly text wrapped beside the infobox and the .hlist/navbox tables below it; not isolated to a feature yet. Servo floats the infobox but wraps the text beside it narrower than Chrome/Firefox (its 10.5 % pixel difference; it gives no boxes to quantify).
• Inline-level elements (.mw-heading h3{display:inline}, .marriage-display-inline, .hlist items, rustdoc's inline <code>) have no box in Blitz's --boxes dump (they live in the text layout) and are reported as 0×0; they count as size differences without being layout differences.
• Replaced elements with a cyclic percentage max-width and a max-height (servo.org: img{max-width:100%;display:block} with .section-feature img{max-height:6rem} and .navbar-brand img{max-height:4rem}): Blitz uses the intrinsic width (401–1024px) as the image's min-content contribution, so the flex: 0 1 25% feature tiles cannot shrink to Chrome's 301px and the navbar brand is 1024px instead of 560px (31/84 boxes, page 5,967 vs 5,445). MDN's logo wrapper (.navigation__logo, around the 83×24 placeholder of an inline SVG) is 99px wide in Blitz and 16px in Chrome; this one is not isolated to a feature yet.
• display: table / table-column / table-row / table-cell on <div>s (the flexbox spec's #overview-example figure): the column and row boxes are 0×0 in Blitz and the figure is 30px shorter (28/471 boxes, +201px over the page from a few such figures).
• Inline-block <code> in prose (rustdoc's .docblock p code{display:inline-block} with white-space:pre-wrap): some paragraphs wrap to one more line in Blitz (24 vs 48px), and the 🔬 in .stab.unstable falls back to no emoji font (511 vs 528px wide); 56/1792 boxes, page height 155,421 vs 155,326 (without the floats feature the page was 6 % taller, 164,853).
• Table rows: Blitz rounds layout to whole pixels, so each of the Bootstrap dashboard's 17 table rows is 1px taller (.table-responsive 544 vs 526px, page +18px). Wikipedia's toolbar tabs are 35px instead of 32px for the same reason (.vector-menu-content, ±3px).
• Ladybird (07fac502): 1.6–6.7 % of pixels differ on every page but Wikipedia (13.1 %) and its body heights match Chrome's page heights within 0.1 % (the flexbox spec and servo.org body is 16 px narrower: Ladybird reserves a scrollbar gutter). Wikipedia's html,body{height:100%} gives an 800 px body whose content overflows, so the dump reports no page height there; the div/p/h3 box counts are lower than Chrome's (812 vs 866) because inline divs/h3s have no block box in the dump, as with Blitz, and are compared as missing.
• The dioxuslabs.com and Bootstrap pixel differences beyond the boxes above are the placeholder images, which Blitz paints without the pages' border-radius/object-fit clipping, and anti-aliasing.

The real pages are not pixel-equal and are not meant to be; the check that matters before timing them is the heights and box counts above, which pin each remaining difference to a feature.