Browser & Frontend Runtime
Render pipeline: multiple-choice review
Crux Multiple-choice synthesis across the render-pipeline unit — stage costs, invalidation blast radius, compositor layers, layout thrash, and production telemetry.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole pipeline. Each one mirrors a decision you make in a real jank investigation — not a stage to name, but a cost to predict and a fix to rank.
Goal
Confirm you can connect the six stages, the invalidation rules, compositor layers, layout thrash, and the production metrics — the synthesis the individual lessons built toward.
Quiz
Completed
A scroll handler animates a list item by writing element.style.top each frame, and the page judders on a mid-range phone. A colleague says it is on the compositor, so it must be the GPU. Why are they wrong?
Heads-up Off-main-thread scroll handles the viewport translate, but writing top inside a handler is a layout-invalidating mutation that runs on the main thread, not the GPU.
Heads-up transform on a promoted layer is composite-only; top invalidates layout. The cost difference is an order of magnitude, which is exactly why the phone janks on one and not the other.
Heads-up rAF batches the invocation to the frame boundary but still runs on the main thread; it does not move layout-invalidating writes off the main thread.
Quiz
Completed
A page renders a 10,000-row feed. style + layout on first paint costs 1,200 ms. You want first paint fast without virtualising (no DOM rewrite). What is the highest-leverage single change?
Heads-up will-change promotes rows to GPU layers (memory cost) but does nothing to skip the style/layout of off-screen rows. It makes the problem worse on mobile GPU memory.
Heads-up rAF batches when the callback runs, not how much layout 10,000 rows cost. The full style+layout still executes for every row.
Heads-up contain: paint clips painting and helps skip off-screen paint, but it does not skip style and layout the way content-visibility: auto display-locking does. Layout still runs for all rows.
Quiz
Completed
You add will-change: transform to one card mid-feed for a smooth hover. DevTools Layer Borders now shows forty promoted boxes. Why, and what is the cost?
Heads-up will-change is a CSS rendering hint with no JS cost. The extra boxes are compositor-induced layers from the overlap rule, and the cost is GPU memory, not CPU.
Heads-up A promoted layer is painted once and then moved on the compositor. The cost is holding the bitmap in GPU memory, not per-frame repaint.
Heads-up They are real compositor layers created by the overlap rule. On a 256 MB mobile GPU budget, dozens of full-area layers trigger tile eviction and worse jank.
Quiz
Completed
The main thread is blocked for 400 ms by a synchronous JSON.parse. A CSS transform animation keeps running at 60 fps; the team rAF-driven animation on the same element freezes. What is the mechanism?
Heads-up It survives because it runs on the compositor at full 60 fps, independent of the blocked main thread — not because it is throttled.
Heads-up Composite-only CSS animations are handed to the compositor thread; rAF runs on the main thread. The difference is architectural, not random.
Heads-up A synchronous JSON.parse runs on the main thread and blocks it; that is precisely why the main-thread rAF animation freezes while the compositor animation does not.
Quiz
Completed
Production RUM reports p75 INP of 340 ms while Lighthouse in the office scores 95. A click handler reads getBoundingClientRect() and then writes styles in a loop. How do you read this and where do you look first?
Heads-up INP from RUM is what real users felt on real hardware. A 340 ms p75 is a genuine interactivity regression that a lab Lighthouse run on fast hardware can easily miss.
Heads-up CLS measures unexpected layout shift; INP measures input-to-next-paint latency. They are different vitals; the forced sync layout in the handler is an INP problem.
Heads-up rAF moves the invocation boundary but a read after a write still forces a synchronous layout flush. The structural fix is to batch all reads before all writes.
Quiz
Completed
A touchmove listener is added without { passive: true } on a scroll container, and scroll fps collapses on mobile. What changed in the pipeline?
Heads-up passive vs non-passive does not change firing frequency. It changes whether the compositor may scroll without waiting for the main-thread handler.
Heads-up A non-passive listener does not consume the event; it forces the browser to wait for the handler before deciding to scroll, falling back to main-thread scroll.
Heads-up The regression is real: compositor-thread scroll becomes main-thread scroll, so scroll fps drops whenever the main thread is busy.
Recap
Across the unit the through-line is one decision chain: the property you change picks the stage you invalidate (transform = composite, color = paint, top/width = layout), dirty bits flow downstream, and containment or content-visibility caps the blast radius. Compositor layers are cheap to move but expensive to hold, the overlap rule promotes neighbours you never asked for, layout thrash comes from reading geometry after a write, and INP plus LoAF close the loop from production telemetry back to a specific stage. Predict the stage, rank the fix, then reach for the compositor.