Stage costs and the renderer process model

Your page parses fast on your M2 MacBook. It crawls on a mid-range Android. The bottleneck is never “the CPU is slow” — it is which thread is doing which work, and how much of it is on the thread that cannot be parallelised.

The renderer process model

A modern Chromium-family browser runs each tab in its own renderer process. Inside that process:

• Main thread — runs HTML parsing, CSSOM construction, style, layout, paint setup, and your JavaScript. It is single-threaded by design: DOM, CSSOM, and JS state can only be mutated by one execution context at a time, otherwise consistency would be impossible.
• Compositor thread — assembles the layer tree and decides which layers need new bitmaps.
• Raster worker threads — rasterise individual tiles in parallel.
• GPU process — takes rasterised tiles, uploads them as textures, and runs the final composite-and-display.

Firefox uses a similar split (Quantum CSS for parallel style, WebRender for GPU-driven compositing); Safari/WebKit splits across its WebContent process and the GPU process. Names differ; the architecture rhyme is universal.

Why the main thread is the bottleneck

Any work you put on the main thread — parsing a JSON blob, deserialising a Redux state, running a layout, executing a click handler — competes for the same 16.67 ms window. The compositor and raster threads exist precisely so rendering work can leave the main thread and run in parallel.

That is the architectural justification for transform/opacity animations being “free”: they reach the GPU without touching the bottleneck thread.

Stage-by-stage cost drivers

Each stage has typical levers that blow up its cost.

Parse HTML scales with document bytes. A 500 KB SSR-rendered page parses faster than a 2 MB one, simply because there is less to walk. Synchronous <script> tags block the parser until they finish downloading and executing — modern best practice puts defer or async on every external script not strictly needed for first paint.

CSSOM cost grows with stylesheet bytes and rule count. An unused 800-rule CSS framework wastes parse time even if zero rules actually match anything on the page.

Style calc cost is roughly DOM size × selectors. A 5 000-node DOM with a 2 000-rule stylesheet is 10 million selector-match checks. Most selectors are skipped via a bloom filter, but :has(), descendant combinators with no ancestor anchor, and universal selectors defeat the filter and cost more.

Layout cost is roughly DOM depth × box dependencies. A deeply nested flexbox with auto sizing forces multiple measure passes; a flat grid with explicit cell sizes is one pass.

Paint cost is painted area × paint op count. box-shadow with a large blur radius and filter properties (blur, drop-shadow) are paint-heavy because each pixel requires multi-pixel sampling.

Composite cost is layer count × layer pixel area. The cheap stages are cheap by orders of magnitude, but only if the upstream stages don’t invalidate downstream.