Browser & Frontend Runtime
Render pipeline: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the pipeline stick.
Reconstruct the unit core mechanisms — the six stages and two threads, the invalidation rules, compositor layers, the frame lifecycle, layout thrash, and the production loop — without looking back at the lessons.
- 01Name the six pipeline stages in order, and say which thread owns each.
- 02Map the three classes of CSS change to the stage they invalidate, and explain how the cost differs.
- 03What does the overlap rule do, and why does one will-change promote a dozen neighbours?
- 04Explain forced synchronous layout and the two-pass fix.
- 05What is the order of events inside one frame, and why does rAF differ from ResizeObserver?
- 06How do INP and LoAF close the production loop, and what two pipeline problems usually cause a poor INP?
If you could reconstruct each answer from memory, you hold the unit spine: six stages on two threads under a 16.67 ms budget, the property you change picks the stage you invalidate, dirty bits flow downstream, compositor layers are cheap to move but expensive to hold (and the overlap rule promotes neighbours), layout thrash is a read after a write fixed by a two-pass batch, the frame lifecycle fixes when rAF and ResizeObserver fire, and INP plus LoAF close the loop from a user-felt slow interaction back to the exact stage that caused it.