Episode 2 — React Frontend Architecture NextJS / 2.19 — Rendering Strategies in NextJS
2.19 — Interview Questions: Rendering Strategies
Use alongside SSR, SSG, ISR. This file also covers App Router cross-cutting ideas: dynamic vs static segments, caching, streaming, and RSC interaction at a conceptual level.
Beginner
Q1. In one sentence, what is SSR?
Model answer: Server-Side Rendering means the HTML for a request is generated on the server at request time (or marked dynamic in the App Router) so the first response can already include data—good for SEO and personalization, at the cost of server work per visit.
Q2. In one sentence, what is SSG?
Model answer: Static Site Generation means pages are pre-rendered ahead of time (typically at build) and served like static files from a CDN—extremely fast and cheap at scale when content does not need to change every second.
Q3. What problem does ISR solve?
Model answer: ISR keeps the performance profile of static pages while allowing them to refresh on a timer or when a webhook triggers revalidation, so you do not rebuild the entire site for every content edit.
Q4. What is streaming with Suspense in an SSR/RSC context trying to improve?
Model answer: It lets the server send HTML in chunks as slower sections become ready, improving perceived performance versus waiting for the entire page tree before the first bytes—especially when one subtree has a slow upstream dependency.
Intermediate
Q5. How does the App Router decide if a route is static or dynamic?
Model answer: Roughly: if the server component tree uses dynamic signals—like reading cookies() or headers(), or using fetch without static caching, or other dynamic APIs per the version docs—Next treats rendering as request-time. If everything in a segment is compatible with static optimization, it can be precomputed. I always verify with the framework output (next build logs) rather than guessing.
Q6. Why can SSR hurt TTFB?
Model answer: TTFB includes everything before the first byte streams: auth, DB queries, upstream APIs, and React rendering. SSR shifts work earlier; if those steps are slow or sequential, the user waits longer before seeing anything. Mitigations: parallelize fetches, add indexes, stream with Suspense, cache selectively.
Q7. When would you refuse ISR for a page?
Model answer: When staleness of any kind is unacceptable—examples: regulated pricing disclaimers that must match the exchange tick-for-tick, or highly personalized financial balances that must never be served from a shared CDN cache. Then I choose SSR, client fetching with private APIs, or a hybrid shell.
Q8. What is the difference between revalidatePath and revalidateTag?
Model answer: revalidatePath invalidates a URL subtree you name—great when you know exactly which pages changed. revalidateTag invalidates data fetches annotated with matching next: { tags: [...] }—better when many routes share the same backing data (e.g., “all posts”).
Q9. How does fetch caching differ mentally between “static page” and “dynamic page”?
Model answer: On static-compatible trees, fetch defaults often behave like cached content across builds/requests (per docs/version). For dynamic routes, I reach for cache: 'no-store' or tag-based revalidation when I need freshness. I never assume default caching without checking the pinned Next version behavior.
Advanced
Q10. Explain stale-while-revalidate to a product manager.
Model answer: We serve the last good version instantly from the edge so the site feels fast. In the background we refresh that version. Until the refresh finishes, some users might see content up to N minutes old. We pick N based on how stale content can be without harming trust or compliance, and we can also invalidate immediately when an editor publishes.
Q11. How do you debug “my ISR page did not update after CMS publish”?
Model answer: I trace the pipeline: Did the CMS webhook fire? Did our Route Handler return 200? Did we call revalidatePath/revalidateTag with the exact path or tag the data fetch used? Is a CDN caching responses longer than we think? I add temporary logging with a content version timestamp embedded in HTML during investigation, then remove it.
Q12. Compare SSR vs client-side rendering for a logged-in dashboard.
Model answer: SSR improves first meaningful paint and can simplify auth for initial data, but hydration cost still matters for heavy interactivity. Many dashboards use SSR or RSC for the shell + permissions, then client components for dense tables, virtualization, and live updates. The decision hinges on SEO (usually irrelevant behind login) vs TTFB vs development complexity.
Q13. How do React Server Components change the SSR story—without hand-waving?
Model answer: Server Components let you keep large data dependencies on the server by default, shrinking client JS. SSR/RSC still compete on TTFB and waterfall discipline—parallelize async work, use Suspense boundaries intentionally, and revalidate caches after mutations so navigations do not show ghost data.
Quick-fire table
| # | Question | One-line answer |
|---|---|---|
| 1 | SSR optimizes? | First HTML with server-fetched data; SEO |
| 2 | SSG optimizes? | CDN-fast delivery; low origin per read |
| 3 | ISR trade-off? | Bounded staleness vs rebuild cost |
| 4 | getServerSideProps runs when? | Each request (Pages Router) |
| 5 | revalidate: N meaning? | Regenerate in background at most every N seconds (Pages ISR mental model) |
| 6 | Risk of SSG for auth pages? | Accidentally leaking private HTML if misconfigured |
| 7 | Streaming helps SSR how? | Earlier bytes; better perceived performance |
| 8 | Tag too broad? | Over-invalidation and origin load |
| 9 | cookies() in RSC? | Usually forces dynamic rendering for that subtree |
| 10 | After mutation in App Router? | Call revalidatePath / revalidateTag (or mutate cache per docs) |
Answers at a glance (2.19.a / 2.19.b / 2.19.c + App Router)
| Lesson | One sentence to remember |
|---|---|
| 2.19.a — SSR | Request-time HTML; best freshness/SEO trade-offs; watch TTFB and waterfalls. |
| 2.19.b — SSG | Build-time HTML; cheapest reads; worst freshness unless rebuilt. |
| 2.19.c — ISR | Serve cached static fast; refresh in background; combine with on-demand revalidation for editorial workflows. |
| App Router | Static vs dynamic is inferred from dynamic APIs + fetch caching; verify with next build. |
| Ops | Measure p95 TTFB, CDN headers, and revalidation logs—do not “cache by vibes.” |