Browser & Frontend Runtime

Eight layers traced: from the service worker to the second navigation

Crux One e-commerce product page followed through all eight layers — network, HTML parse, CSS, V8, first paint, hydration, the interaction, and the second navigation — with the budget numbers for each.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at middle altitude — in the sky

◷ 18 min

One e-commerce product page: server-rendered, React-based, hero image, “Add to cart” button, a registered service worker. A mid-range Android phone, 4G. What exactly happens — in which order, across which threads, spending how much time — from the moment the user taps the link to the moment the cart badge updates?

The page we are tracing.

One concrete page: an e-commerce product page, server-rendered, React-based, with a hero image, a price, an “Add to cart” button, a reviews section below the fold, and a service worker registered from a previous visit. The user is on a mid-range Android phone on 4G. We follow this exact page from the moment they tap a link to the moment they successfully add the item to the cart.

Layer 1 — Network.

The tap triggers a navigation. DNS resolves the host, a TLS handshake secures the connection, and an HTTP request goes out. But there is a twist: a service worker from a prior visit is registered. The browser gives the service worker’s fetch handler the first look — it can serve the navigation from cache or pass it through to the network. Either way, the first byte of HTML arrives. This is TTFB, and it is the floor under everything: nothing downstream can start before the bytes are here.

Layer 2 — HTML parse and the preload scanner.

The HTML parser begins turning bytes into a DOM tree, top to bottom. Running ahead of it is the preload scanner, spotting <img>, <script>, and <link> references and kicking off their downloads early. This is why the hero image, sitting in the initial HTML as a plain <img>, starts downloading immediately — the LCP clock is already ticking and discovery happens as early as possible. A render-blocking <script> in the <head> would pause the main parser here; a defer’d one would not.

Layer 3 — CSS and the CSSOM.

As <link rel="stylesheet"> resources arrive, the browser parses them into the CSSOM. CSS is render-blocking by design: the browser will not paint until it has the CSSOM, because painting with incomplete styles would mean a flash of unstyled content. The DOM and CSSOM together form the render tree. If the CSS is large or served slowly, every paint downstream waits.

Layer 4 — JavaScript: V8 parse and compile.

The JavaScript bundle arrives and V8 goes to work — but not by running it immediately. V8 first parses the source and compiles it to bytecode (the Ignition interpreter’s input). For a large bundle this parse-and-compile step alone is tens to hundreds of milliseconds of main-thread time on a mid-range phone, before a single line has executed. This is the hidden cost inside “the JavaScript is too big”: the bytes are not just a download, they are CPU work.

Layer 5 — First paint.

With the render tree ready, the render pipeline runs: style, layout, paint, composite. The product photo, price, and layout appear. The hero image, if it has finished downloading, paints — and this is very likely the LCP moment, the largest contentful element arriving. The page now looks done. But it is a picture: no handler is attached, no state is live.

Layer 6 — Hydration.

Now React runs hydrateRoot. It walks the same component tree the server walked, and instead of creating DOM nodes it adopts the existing server DOM, attaching event handlers and wiring up state and effects — the reconciler in hydration mode. This is one long task: V8 executes the component tree, the reconciler does its render and commit. While it runs, the main thread is blocked. The page looked done at layer 5; it becomes actually interactive only when hydration reaches each component.

Layer 7 — The interaction.

The user taps “Add to cart.” If they tap before hydration reached that button, the input is delayed — queued behind the hydration long task — and INP records a large latency. If they tap after, the handler runs: it updates cart state, the reconciler re-renders the cart badge, the render pipeline paints the change. The time from tap to that paint is one INP sample.

Layer 8 — The second navigation and the worker.

The user navigates to checkout. Now the service worker earns its keep: it serves the app shell from cache, so the second navigation’s TTFB is tens of milliseconds instead of a network round trip.

The trace, in numbers (mid-range phone, 4G)

TTFB — network served: ~300 ms
TTFB — service worker cache: ~30 ms
JS parse + compile (V8): ~150 ms
Hydration long task: 300 ms – 1 s+
Good LCP / INP / CLS: 2.5 s / 200 ms / 0.1
Canonical break count: 5, one per domain

The overlapped timeline — three tracks, not one sequence.

The crucial insight is that these layers are not a tidy sequence — they overlap on a timeline across three resources:

The network track is busy fetching HTML, then CSS, then the JS bundle, then the image, in parallel where the protocol allows.
The main thread track is busy parsing HTML, then compiling JS, then painting, then running the hydration long task.
The GPU track does the final composite.

A DevTools performance trace shows exactly these three tracks. Reading a slow page means finding which track is the bottleneck at the moment that matters — network-bound before first paint, main-thread-bound during hydration. The skill is not knowing the layers; it is reading where, on the overlapped timeline, the time actually went.

Parallelism: why the layers are not sequential.

The browser does not do one step, wait, do the next — it keeps all three resources busy whenever there is work. While the network downloads the JS bundle, the main thread is already parsing the HTML that arrived earlier. While the main thread compiles the JS, the network is already fetching the image. The preload scanner exists precisely for this parallelism — it finds resources and throws them onto the network while the main parser is busy with something else.

The diagnostic consequence: a “slow page” is almost never one slow step. It is the moment where parallelism broke down, where one track became the constraint and the other two sat idle waiting for it. A render-blocking script is the classic example: it stops the main parser, and while it downloads, the main thread is idle even though it could be parsing the rest of the HTML.

Quiz

On the second navigation (to checkout), TTFB drops from ~300 ms to ~30 ms. Which layer is responsible?

Quiz

On the trace, V8 spends ~150 ms before a single line of the bundle has executed. What is it doing?

Trace it

1/3

A DevTools trace of the product page: LCP fires at 1.5 s (good). But there is a 900 ms main-thread long task starting at 1.6 s, and the user's tap on 'Add to cart' at 2.0 s shows an INP of 700 ms. What is the long task, and why is INP bad despite a good LCP?

Step 1 of 3

The 900 ms long task is hydration — V8 executing the component tree and the reconciler adopting the server DOM; the 2.0 s tap landed inside it, so INP recorded the wait

Locked

The long task is the network fetching images

Locked

INP is bad because LCP was bad

Quiz

Why is reading a DevTools trace described as finding the bottleneck 'track', not the bottleneck 'layer'?

Order the steps

Order the eight layers of the page's life, from the user's tap to the second navigation.

1 Network — DNS, TLS, HTTP; service worker gets first look
2 HTML parse — DOM tree, preload scanner discovers resources
3 CSS — CSSOM built, render tree formed
4 V8 — JS bundle parsed and compiled to bytecode
5 First paint — layout, paint, composite; LCP fires
6 Hydration — reconciler adopts server DOM, attaches handlers
7 Interaction — tap handled, re-render, INP measured
8 Second navigation — service worker serves the app shell

Complete the analogy

A good LCP and a bad INP coexisting — the page paints fast but cannot be tapped — has a name. It describes the window where the page is a convincing picture that does not respond. What is that window called?

Compute it

On the trace, the JS bundle parse-and-compile in V8 takes about how many milliseconds for a typical bundle on a mid-range phone — the cost before any line executes?

Why this works

The eight layers are not an arbitrary list — they are the shape the web acquired over thirty years of evolution. Early pages were layers 1–3 and nothing else: network, parse, paint — a static document. JavaScript added execution, and layer 4 (V8) became significant. AJAX and SPAs pushed rendering into the browser, killing layer 5 as “first paint of something useful.” SSR brought server rendering back for fast first paint and SEO — but it also introduced layer 6, hydration, and with it the uncanny valley. Service workers (layer 8) were added to win back the instant repeat loads lost when sites moved away from static files. Each layer is a solution to a past tradeoff that became a new tradeoff.

Recall before you leave

01
Trace the e-commerce product page from the user's tap to a working 'Add to cart' button, naming each of the eight layers.
02
What is the three-track structure of a DevTools trace, and why does 'finding the bottleneck track' matter more than 'finding the slow layer'?
03
Why does V8 spend ~150 ms before a single line of the bundle executes, and what does this cost affect?

Recap

A server-rendered, React-based product page traverses eight layers: network (TTFB ~300 ms, or ~30 ms from service worker cache), HTML parse with preload scanner starting the hero image early, CSS building the CSSOM (render-blocking), V8 parse-and-compile (~150 ms of main-thread work before execution), first paint and LCP, a hydration long task (300 ms to 1 s+) that blocks early taps, the interaction (INP measured tap-to-paint), and a second navigation served from cache. These eight layers run on three overlapping tracks — network, main thread, and GPU — not a single sequence. Parallelism is the norm; a bottleneck is the moment one track stalls and the others wait. The hydration uncanny valley — good LCP, bad early INP — is the structural failure of server-rendered apps: the page looks done before it works, and every tap inside the hydration long task is a delayed interaction the user feels.

Connected lessons

builds on

unlocks

Five canonical breaks: where production reliably diessenior

deepens into

appears again in278

Continue the climb ↑Five canonical breaks: where production reliably dies