ESC

Type to search the knowledge base.

Next.js Rendering Modes

SSR, SSG, ISR, and client rendering — when each helps, and how to talk about them in interviews.

intermediate2 min read
  • nextjs
  • ssr
  • ssg
  • rendering

Next.js is a routing and rendering toolkit on top of React. Interviews probe whether you can pick a rendering strategy for a page’s data freshness, SEO, and TTFB needs.

Modes (conceptual)

Mode When HTML is produced Best for
SSG Build time Docs, marketing, changelogs
SSR Each request Personalized, highly dynamic SEO pages
ISR Build + revalidate Catalogs that update periodically
Client Browser Dashboards behind auth, highly interactive widgets

App Router uses Server Components by default, with explicit "use client" boundaries. Pages Router used getStaticProps / getServerSideProps. Speak to both if your target company still runs Pages Router.

Decision checklist

  1. Does the page need to be indexed with meaningful content? → server-rendered HTML helps
  2. Is data user-specific? → avoid shared static cache without variation
  3. Can data be stale for N seconds? → revalidate / ISR
  4. Is the interaction heavy and private? → client fetch after shell

Streaming

Streaming SSR sends HTML in chunks so the shell paints while slow components wait. Use loading UI (loading.tsx / Suspense) so users see structure early.

Common mistakes

  • Fetching everything client-side “for simplicity” and losing SEO + performance
  • SSG of personalized pages
  • Giant client bundles because Server Components were never leveraged
  • Caching authenticated responses at the CDN incorrectly

Interview one-liner

“Pick where HTML and data are bound: build, request, or browser — based on freshness, personalization, and critical path. Next is a set of defaults around that choice.”

Related guides