Browser & Frontend Runtime
Render strategies: 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 mechanism stick, not recognising it on the page.
Reconstruct the unit’s core mechanisms — when each strategy renders, why hydration costs ~2×, what breaks the hydration contract, and how RSC and streaming compose — without looking back at the lessons.
- 01SSG, SSR, ISR, streaming SSR — define each by WHEN the HTML is produced, and name the cost each one pays.
- 02Why does hydration cost roughly 2× the server render, and why is it worse than a plain doubling?
- 03What is a hydration mismatch, what are its common causes, and what is the determinism rule that prevents it?
- 04Why must the server's API data be embedded in the HTML, and what mechanism do frameworks use?
- 05RSC and SSR are described as orthogonal. What does each axis control, and how does a single Next.js App Router page use both?
- 06Give the per-route decision frame for marketing homepage, product pages, account dashboard, and checkout — with the reason for each.
If you could reconstruct each answer from memory, you hold the unit’s spine: WHEN the HTML is produced spans SSG → ISR → SSR → streaming, trading freshness against server cost on the critical path; hydration is the ~2× re-render that runs on the user’s device and gates interactivity (INP); the hydration contract breaks on any non-deterministic value read during render and on a data snapshot that differs from the server’s; RSC is an orthogonal axis that removes server-only components from the client bundle entirely; and the right answer is always per-route, chosen by freshness, interactivity, and data latency.