Next.jsSSRSSGCachingmiddle level

SSR, SSG, and ISR: Choosing the Right Render Time

the question

What is the difference between SSR, SSG, and ISR in Next.js, and when would you choose each one?

what they're testing: The interviewer is testing whether you can match freshness and personalization requirements to the right rendering and caching trade-offs.

a strong answer

SSR renders a route at request time. Choose it when the output depends on request-specific values such as cookies or headers, or when data must be checked for each request. It suits personalized dashboards and frequently changing pages, but it requires server work whenever the response is not served from a cache. Request-time rendering also does not guarantee fresh upstream data if another cache is involved.

SSG prerenders a page, usually during next build, and reuses the generated HTML for later requests. It can fetch external data while building. Choose it for documentation, marketing pages, or other content that can remain unchanged until the next build. Static output is inexpensive to serve and can be cached by a CDN.

ISR adds revalidation to static generation, so a cached page can change without rebuilding the whole site. With time-based revalidation, the first request after the interval receives the stale page while Next.js regenerates it in the background. On-demand APIs such as revalidatePath and revalidateTag invalidate cached content after an event. Choose ISR for product pages, articles, or catalogs where fast static delivery matters and brief staleness is acceptable.

Where people slip

the tempting wrong answer, and what's actually true

ISR rebuilds the page automatically at fixed intervals, even when nobody visits it.
With time-based ISR, a request after the interval serves the stale page and triggers background regeneration.
SSG can only render hardcoded content because data fetching requires SSR.
SSG can fetch external data during the build and use it to prerender the page.
SSR guarantees fresh data because nothing involved in the response can be cached.
SSR renders at request time, but an upstream data source or the SSR response itself can still be cached.

If they push further

How would you implement these strategies in the Pages Router versus the App Router?

In the Pages Router, compare `getServerSideProps`, `getStaticProps`, and the `revalidate` option returned by `getStaticProps`. In the App Router, explain request-time rendering, prerendering, and the route or cache revalidation APIs.

What happens if an ISR regeneration fails?

Next.js keeps serving the last successfully generated version and retries revalidation on a later request.

When would you prefer on-demand revalidation over a time interval?

Use it when an event such as a CMS publish or product update can identify exactly when a cached path or tag became stale.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.