How browsers turn HTML and CSS into pixels — the critical rendering path
The critical rendering path is the sequence of steps a browser runs to turn HTML, CSS, and JavaScript into the pixels a user sees — parse HTML into the DOM, parse CSS into the CSSOM, combine them into a render tree, lay out the geometry, paint the pixels, and composite the layers to screen. The faster the browser finishes that path for the parts of the page that matter on first view, the better your LCP, INP, and CLS look. Every performance tactic — defer, async, <link rel="preload">, content-visibility: auto, fetchpriority="high" — exists to shorten or unblock one specific step of that path.
This post walks the whole pipeline end-to-end, names what blocks each step, and shows the code patterns that turn a render-blocking page into one that paints in under 2.5 seconds.
Key takeaways
- The path has six steps: HTML → DOM, CSS → CSSOM, Render tree, Layout, Paint, Composite. Every perf optimisation maps to one of them.
- CSS is render-blocking by default. Synchronous JavaScript in
<head>is both render- and parser-blocking. Move scripts to the end or usedefer. deferis almost always the right choice for app code.asynconly fits truly independent scripts like analytics. ES modulesdeferautomatically.- Reflow > repaint > composite, in cost. Animate
transformandopacityinstead oftop,width, orheightand you skip the first two entirely. - Core Web Vitals map cleanly onto rendering steps: LCP measures how fast the largest paintable element finishes the path, INP measures the round-trip from input to next paint, CLS measures layout shifts inside step four. Current "good" thresholds are LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1, per Google's Core Web Vitals documentation.
The six steps, end to end
A simplified picture of what happens between the response arriving and the first frame appearing:
HTTP response bytes
│
▼
┌──────────────────┐ ┌──────────────────┐
│ HTML parser │ │ CSS parser │
│ (tokenize + │ │ (tokenize + │
│ tree-build) │ │ cascade) │
└────────┬─────────┘ └────────┬─────────┘
▼ ▼
DOM CSSOM
│ │
└────────────┬───────────────┘
▼
Render tree
(only visible nodes,
with their styles)
│
▼
Layout
(geometry — x, y,
width, height)
│
▼
Paint
(rasterise pixels
into layers)
│
▼
Composite
(assemble layers
on the GPU → screen)
That's the canonical pipeline. Modern Chromium splits a few of these into sub-stages (style resolution, pre-paint, raster, draw), and the renderer runs them on multiple threads, but as a mental model the six-step view is what every senior frontend engineer keeps in their head.
Step 1 — HTML to DOM
The browser streams bytes off the network and feeds them to the HTML parser. The parser tokenises the markup (<div>, attribute names, text) and builds the Document Object Model: a tree of nodes that represents the document structure. Parsing is incremental — the DOM grows as bytes arrive — which is why streaming HTML matters and why <head> ordering has outsized impact.
Step 2 — CSS to CSSOM
Stylesheets are parsed in parallel into the CSS Object Model. The CSSOM looks similar to the DOM but with every rule resolved against the cascade (selector specificity, inheritance, !important, layers). Until the CSSOM is complete, the browser cannot accurately compute the styles for any node — which is why CSS is render-blocking. Mozilla's reference on the critical rendering path covers the cascade rules in detail.
Step 3 — Render tree
The DOM and the CSSOM are combined into a render tree. It contains only the visible nodes — <head> is excluded, anything with display: none is excluded, and each remaining node carries its computed style. Note that visibility: hidden and opacity: 0 elements are in the render tree (they take up space), but display: none elements are not (they don't).
Step 4 — Layout
Layout (sometimes called reflow) computes the geometry of every node — exact pixel position, width, height, baseline, line breaks. This is where viewport size matters, where flexbox and grid resolve, where text wraps. Any change to a node's box (font size, content length, width) invalidates layout for that node and possibly its ancestors and siblings. Layout is the most expensive step the browser runs frequently, which is why "avoid layout thrashing" is such a constant refrain.
Step 5 — Paint
Paint walks the render tree and produces drawing commands — fill this rectangle red, stroke this line, draw this text glyph. Modern browsers paint into layers (separate raster surfaces) when promotion conditions are met: transform, opacity, will-change, <video>, <canvas>, position: fixed, and a few others.
Step 6 — Composite
The compositor takes the painted layers and assembles them on the GPU — translating, scaling, and blending them into the final frame. Because compositing happens on the GPU and doesn't require re-layout or re-paint, it's by far the cheapest step. This is why animating transform and opacity is so much cheaper than animating top or width — the former only touches step 6, the latter forces a return to step 4.
What blocks rendering
Three classes of resource get between bytes arriving and pixels appearing.
Synchronous scripts in <head> block both parsing and rendering
When the HTML parser hits a <script src="..."> without defer or async, it stops. It downloads the script, hands it to the JS engine, waits for execution to finish, and only then resumes parsing. The DOM stops growing during that pause — and because the DOM stops growing, the render tree can't update, and the page can't paint.
A script tag right before </body> avoids the worst of this because most of the DOM is already built by the time it executes. A script tag in <head> is the textbook render-blocker.
CSS blocks rendering until the CSSOM is built
CSS is render-blocking by default. The browser won't paint a first frame while there's any unprocessed stylesheet, because doing so would risk flashing unstyled content. This is a feature, not a bug — but it does mean an enormous main.css or a slow CDN can hold up every other paint on the page. Splitting critical CSS inline into the head and loading the rest with <link rel="preload" as="style" onload="this.rel='stylesheet'"> is the classic mitigation.
Web fonts can delay text rendering
A late-loading font file can either flash unstyled text (FOUT) or hold text invisible until the font arrives (FOIT). font-display: swap in @font-face opts into FOUT — text renders immediately in the fallback, then swaps when the custom font lands. Most teams want swap. The exception is brand-critical typography on the LCP element, where the swap itself causes a layout shift; for that case, preload the font and use font-display: optional.
<link
rel="preload"
href="/fonts/inter-var.woff2"
as="font"
type="font/woff2"
crossorigin
/>
defer vs async vs <script type="module">
Three ways to load a script, all with subtly different effects on the parser.
<!-- 1. Blocking — the parser stops here until the script downloads and runs -->
<script src="/app.js"></script>
<!-- 2. async — downloads in parallel with parsing, executes AS SOON AS it's ready, possibly mid-parse. Order between async scripts is not preserved. -->
<script async src="/analytics.js"></script>
<!-- 3. defer — downloads in parallel with parsing, executes ONLY AFTER the parser finishes, in source order. -->
<script defer src="/app.js"></script>
<!-- 4. ES module — defers automatically (same behaviour as `defer`), runs in strict mode, has its own scope, supports top-level `import` -->
<script type="module" src="/app.mjs"></script>
| Attribute | Downloads | Executes | Order preserved | When to use |
|---|---|---|---|---|
| (none) | Blocks parsing | Immediately, mid-parse | Yes | Almost never. Inline-only init code is the exception. |
async | Parallel | As soon as fetched (can interrupt parsing) | No | Independent third-party scripts (analytics, ads, A/B tags) |
defer | Parallel | After parsing, before DOMContentLoaded | Yes | Your app code, anything that touches the DOM |
type="module" | Parallel | After parsing, in source order | Yes | Modern ES modules. defer is the default. |
type="module" async | Parallel | As soon as the module graph resolves | No | Standalone modules with no inter-dependencies |
defer is the right default for application code. async is right for fire-and-forget scripts. ES modules behave as deferred by default — which is why a <script type="module"> in <head> doesn't block parsing the way a classic script there would.
How display: none vs visibility: hidden affect the path
A small but high-impact distinction.
display: noneremoves the element from the render tree. It takes no layout space, costs nothing to paint, and is invisible to layout calculations. Toggling it forces a layout pass when it returns.visibility: hiddenkeeps the element in the render tree. It takes layout space, costs paint (the engine still walks it), but isn't drawn. Toggling betweenvisibleandhiddenonly triggers paint, not layout.opacity: 0keeps the element in the render tree, takes layout space, and on a composited layer can be animated on the GPU. Togglingopacitybetween 0 and 1 on a layer-promoted element is the cheapest visibility change available.
If you're toggling a tooltip 60 times a second, opacity on a transform-promoted layer beats display: none by orders of magnitude.
Reflow vs repaint vs composite — which CSS properties cost what
Every CSS change you make falls into one of three buckets. Picking the right bucket can be the difference between 60fps and a janky 12fps scroll.
| Change triggers | Steps re-run | Example properties | Cost |
|---|---|---|---|
| Layout (reflow) | Layout → Paint → Composite | width, height, top, left, padding, margin, display, font-size, border | Highest |
| Paint (repaint) | Paint → Composite | color, background-color, background-image, box-shadow, border-radius (sometimes) | Medium |
| Composite | Composite only | transform, opacity, filter (on a promoted layer) | Lowest |
CSS Triggers (community-maintained) keeps the property-by-property breakdown current. The headline rules of thumb:
- Animate
transformandopacity, nottop/left/width/height. Atransform: translateX()runs entirely on the GPU compositor. - Don't read layout properties in a write loop. Reading
offsetTop,clientHeight,getBoundingClientRect()forces the browser to flush pending style and layout to give you a current answer. Reading-then-writing-then-reading-then-writing is the textbook layout thrash. Batch reads, then batch writes. - Promote sparingly.
will-change: transformhints to the browser that this element should be on its own layer. Overuse — applying it to dozens of elements — eats GPU memory and can actually slow the page down.
Forced synchronous layout (layout thrash) shows up in Chrome DevTools as red triangles in the Performance panel, and the Insights sidebar flags it as "Forced reflow" with a link to the offending line.
Core Web Vitals — which step each metric measures
In 2026 the three Core Web Vitals remain Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, per Google's announcement. Each metric maps to a different point on the rendering path.
| Metric | What it measures | Which rendering steps drive it | "Good" threshold (75th percentile) |
|---|---|---|---|
| LCP | Time from navigation start to the largest visible element finishing render | Steps 1–6 for the LCP element specifically | ≤ 2.5 seconds |
| INP | Time from user input (click, tap, key) to the next visual update | Main-thread work + steps 4–6 to next paint | ≤ 200 milliseconds |
| CLS | Sum of unexpected layout shifts during the page lifecycle, weighted by impact fraction × distance | Step 4 (layout) firing after first paint | ≤ 0.1 |
LCP — the full pipeline for one element
LCP is essentially "how long does the critical rendering path take for the largest paintable element". The four phases the Chrome team breaks it into — TTFB, resource load delay, resource load duration, element render delay — sit at different points on the path. TTFB is server response. Load delay and duration measure how quickly the LCP resource (usually an image) is fetched. Render delay is what happens after the resource lands but before paint — typically CSS still loading, JavaScript still parsing, or fonts still arriving.
INP — input to paint, end-to-end
INP measures the latency from user interaction to the next frame the browser paints. The three phases — input delay, processing duration, presentation delay — correspond to: how long the main thread was busy before your handler ran, how long your handler took, and how long it took for the browser to recompute layout/paint/composite and present a frame. A heavy handler that does a large DOM update lands all three components at once.
CLS — layout firing when the user didn't ask for it
CLS is unique among the three because it measures step four happening after the user thinks the page has settled. An image without width/height attributes pushes content down when it loads. An ad iframe injecting itself moves the article. A late-loading font swap reflows text. Each of those is a layout pass that the user experiences as content jumping.
Common performance wins by understanding the path
Once the mental model clicks, most performance "tricks" stop being tricks and become obvious mechanical moves.
Preconnect to critical third-party origins
<link rel="preconnect"> opens a TCP and TLS connection to an origin you know you'll fetch from, before any actual request fires. Saves 100–500ms on the first request.
<link rel="preconnect" href="https://cdn.example.com" crossorigin />
<link rel="dns-prefetch" href="https://cdn.example.com" />
Preload the LCP image and key fonts
<link rel="preload"> tells the browser to fetch a resource with high priority even before the parser would discover it. Use it for the hero image, the variable font your LCP text depends on, and any critical CSS file loaded via JavaScript.
Mark the LCP image with fetchpriority="high"
The fetchpriority attribute has been Baseline-available since October 2024 and is now safe to ship without fallback. Browsers default <img> to low priority, which is wrong for the hero image. Mark it high.
<img
src="/hero.avif"
fetchpriority="high"
width="1280"
height="720"
alt="Product overview"
/>
Google Flights reported LCP dropping from 2.6s to 1.9s — a 27% improvement — after adding fetchpriority="high" to their hero image (see web.dev case study).
Reserve space — width and height, or aspect-ratio
CLS is mostly caused by elements that don't reserve space before they load. Set width and height on every <img> and <iframe>. For containers, aspect-ratio: 16 / 9 reserves height as soon as the box width is known. The CLS-eliminating effect is dramatic on image-heavy pages.
Use content-visibility: auto for long pages
content-visibility: auto tells the browser to skip layout and paint for sections that are off-screen, then render them as they near the viewport. It's now supported in all three major engines (Chrome 85+, Edge 85+, Safari 18+, Firefox 125+). Pair it with contain-intrinsic-size so the scrollbar doesn't jump.
article.section {
content-visibility: auto;
contain-intrinsic-size: 0 800px;
}
The web.dev case study reports rendering time on a long article dropping from 232ms to 30ms — roughly a 7x speed-up on first paint.
Defer non-critical CSS
<!-- Critical CSS inlined in the head -->
<style>
/* above-the-fold rules only */
</style>
<!-- Everything else loaded without blocking render -->
<link
rel="preload"
href="/styles/main.css"
as="style"
onload="this.rel='stylesheet'"
/>
<noscript><link rel="stylesheet" href="/styles/main.css" /></noscript>
Speculation Rules for instant next-navigation
Newer to the toolbox: the Speculation Rules API lets you tell the browser to prerender likely next navigations. Currently Chromium-only — Chrome, Edge, Opera. Other browsers ignore the rules safely.
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/product/*" },
"eagerness": "moderate"
}
]
}
</script>
Across sites monitored by CoreDash, prerendered navigations show a 75th-percentile LCP of 320ms compared to 1,800ms for standard navigations — an 82% improvement from one API.
A worked example: render-blocking page vs optimised page
Before — every classic mistake in one file:
<!doctype html>
<html lang="en">
<head>
<title>Slow Product Page</title>
<!-- Render-blocking, no preconnect -->
<link rel="stylesheet" href="https://cdn.example.com/bundle.css" />
<!-- Synchronous, parser-blocking -->
<script src="https://cdn.example.com/jquery.js"></script>
<script src="https://cdn.example.com/analytics.js"></script>
<script src="/app.js"></script>
<!-- Late-loading font, no preload, no font-display -->
<link rel="stylesheet" href="/fonts.css" />
</head>
<body>
<!-- No dimensions, no fetchpriority — image arrives late, shifts layout -->
<img src="/hero-2400.jpg" alt="Hero" />
<h1>Product</h1>
<!-- ...lots more content... -->
</body>
</html>
After — the same page, with the critical rendering path actually respected:
<!doctype html>
<html lang="en">
<head>
<title>Fast Product Page</title>
<!-- Warm up the CDN connection -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin />
<!-- Preload the LCP image and the variable font -->
<link
rel="preload"
as="image"
href="/hero-1200.avif"
fetchpriority="high"
/>
<link
rel="preload"
href="/fonts/inter-var.woff2"
as="font"
type="font/woff2"
crossorigin
/>
<!-- Critical CSS inlined -->
<style>
/* above-the-fold rules only */
body {
font-family: 'Inter', system-ui, sans-serif;
margin: 0;
}
.hero {
aspect-ratio: 16 / 9;
}
</style>
<!-- Non-critical CSS loaded without blocking -->
<link
rel="preload"
href="/styles/main.css"
as="style"
onload="this.rel='stylesheet'"
/>
<noscript><link rel="stylesheet" href="/styles/main.css" /></noscript>
<!-- App code deferred — runs after parsing, in order -->
<script defer src="/app.js"></script>
<!-- Analytics is fire-and-forget -->
<script async src="https://cdn.example.com/analytics.js"></script>
</head>
<body>
<img
class="hero"
src="/hero-1200.avif"
width="1200"
height="675"
fetchpriority="high"
alt="Product overview"
/>
<h1>Product</h1>
<!-- ...lots more content, sections use content-visibility: auto... -->
</body>
</html>
The "after" version unblocks the parser, paints the LCP image earlier, reserves space so the H1 doesn't jump, and uses defer so JavaScript runs after the DOM is built instead of mid-construction. On a mid-tier Android over 4G the difference is typically 1.5 to 3 seconds of LCP and a CLS that drops from 0.2-something to near zero.
FAQ
What is the critical rendering path in simple terms?
It's the chain of steps the browser runs to get from raw HTML, CSS, and JavaScript to the first painted pixel — parsing HTML into the DOM, parsing CSS into the CSSOM, combining them into a render tree, laying out the geometry, painting, and compositing. Everything that's slow about the web fits somewhere in those six steps.
Is defer or async better for my main app bundle?
defer. async executes whenever the script downloads, possibly mid-parse, and doesn't guarantee order between scripts — both are wrong for application code that touches the DOM or depends on other scripts. Use defer for your bundle and reserve async for independent third-party scripts like analytics tags.
Does ES module <script type="module"> need defer?
No. Modules are deferred by default — they execute after the parser finishes, in source order. Adding defer to a module script is harmless but redundant. Adding async to a module script changes the behaviour: it executes as soon as the module graph resolves, without waiting for parsing.
What's the difference between reflow, repaint, and composite?
Reflow recomputes geometry (layout). Repaint redraws pixels into a layer. Composite assembles layers on the GPU. Reflow is the most expensive and triggers repaint and composite after it. Repaint triggers composite. Composite-only changes (like transform and opacity on a promoted layer) are cheap enough to run at 60+ fps without help.
Which Core Web Vital is affected most by render-blocking resources?
LCP, almost always. Render-blocking CSS and synchronous scripts in <head> delay the entire critical rendering path, which delays when the largest element can paint. INP suffers from main-thread JavaScript work after load, and CLS suffers from missing image dimensions and late-loading fonts — but render-blocking resources are an LCP problem first.
Is content-visibility: auto safe to use in production?
Yes, in 2026. It works in Chrome 85+, Edge 85+, Safari 18+, and Firefox 125+ — the three major engines. For long content pages it's one of the highest-ROI single-property changes available. Pair it with contain-intrinsic-size so scrollbar height stays stable as sections render.
What's the 2026 status of the Speculation Rules API?
It's Chromium-only — Chrome, Edge, Opera. Firefox and Safari currently ignore the rules without error, so it's safe to ship as progressive enhancement. Chrome 144 (January 2026) added a "prerender until script" mode that fetches HTML and subresources but pauses before any script side effects, addressing earlier concerns about analytics firing on prerendered pages.
Where Crosscheck fits
The critical rendering path turns "the page feels slow" from a vague complaint into a specific step that's running too long. Where Crosscheck enters the loop is the moment after — when a tester or developer spots an LCP regression, a layout shift, or a janky interaction and needs to file a bug the team can actually reproduce. Crosscheck is a free Chrome extension that captures the screen recording, console output, network timings, and browser metadata for the failing session, and sends it straight to Jira, Linear, ClickUp, GitHub, or Slack — so the engineer fixing the render-blocking script doesn't have to re-create the trace from scratch.
For the diagnostic side, the Crosscheck team has also written about Chrome DevTools performance auditing, JavaScript debugging tips for developers, and the perfect bug report template.
