Browser & Frontend Runtime
Render strategies: a per-route rendering audit
Reading about render strategies is not the same as choosing one per route under real constraints. Build a small four-route app, assign each route the strategy its freshness and interactivity demand, then prove the choices with TTFB, LCP, INP, and a hydration-mismatch count — and fix the regressions you find.
Turn the unit’s two-axis model into a reproducible engineering loop: pick a strategy per route, minimise the hydration surface with RSC and islands, defend render determinism, instrument the metrics that catch regressions, and verify each decision with before/after numbers.
Build (or take) a small app with four routes — a marketing homepage, a product page with a frequently-updating price, a per-user dashboard with one slow query, and a checkout form — assign each route the right rendering strategy, and prove every choice with measured TTFB, LCP, INP, and a zero hydration-mismatch count.
- A per-route table: strategy chosen, TTFB, LCP, INP (p75), and bundle size — measured, not estimated — with a one-line justification per route.
- The hydration-mismatch route shows the warning and CLS before the fix, and zero mismatch warnings with CLS back to ~0 after — both captured.
- The dashboard waterfall shows shell-first flush (~50 ms) with the slow boundary streaming in later; removing the Suspense boundary visibly delays TTFB to ~400 ms.
- INP at p75 stays under 200 ms on every route, and the client bundle shrinks measurably after pushing 'use client' down to leaves.
- A one-paragraph write-up: for each route, the freshness × interactivity driver behind the strategy, and why it beat the alternatives.
- Add a CI gate that fails the build on any new hydration-mismatch error and on an INP-p75 regression above 200 ms on a canary route.
- Compare ISR on-demand revalidation propagation across simulated CDN POPs: show the brief window where some POPs serve old and others serve new, and document the bounded-staleness trade.
- Add a dehydrated query cache (React Query/SWR) on the dashboard so the first client render uses the server's snapshot, and show the data-driven mismatch that appears if you refetch before hydration instead.
- Swap the dashboard from full hydration to islands (or push more 'use client' down) and quantify the INP and bundle-size delta on a low-end mobile CPU profile.
This is the loop you will run designing any real app: choose the strategy per route by freshness × interactivity × data latency (SSG → ISR → streaming SSR → SSR), minimise the hydration surface by keeping Server Components the default and pushing ‘use client’ to leaves, defend render determinism so the hydration contract holds, instrument TTFB/LCP/INP/mismatch-rate, and verify every decision with before/after numbers under realistic load. Doing it once on a four-route toy app makes the production architecture muscle memory.