SSR vs SSG vs ISR: What Is the Difference?
Understand SSR, SSG, and ISR rendering strategies — how each generates HTML, freshness tradeoffs, and when to use them.
Expected Interview Answer
SSR (server-side rendering) generates the HTML for a page on every request, SSG (static site generation) generates the HTML once at build time and serves the same file to everyone, and ISR (incremental static regeneration) serves a static file like SSG but automatically regenerates it in the background after a configured time interval, giving near-static speed with periodically fresh data.
With SSR, each incoming request runs the render on the server, fetching whatever data is needed at that moment, so the page is always fully current but every request pays the cost of rendering and data fetching — this suits highly personalized or frequently changing pages like a logged-in dashboard. With SSG, the HTML is produced once during the build pipeline and then served as a static file from a CDN forever (until the next deploy), which is extremely fast and cheap to scale but means the content is only as fresh as the last build — ideal for marketing pages or blog posts that rarely change. ISR bridges the gap: pages are built statically like SSG, but each page carries a revalidation window (e.g. revalidate: 60), so after that time the next request triggers a background regeneration while still serving the stale cached version instantly (stale-while-revalidate), and subsequent requests get the newly built version. The real decision axis is freshness requirement versus scale/cost: SSR for always-current personalized content, SSG for content that changes rarely, and ISR for content that changes occasionally but where you still want static-file speed for most requests.
- SSR guarantees fresh, request-time-accurate content for personalized pages
- SSG delivers the fastest possible response since pages are pre-built static files
- ISR combines static-file speed with periodic freshness without a full rebuild
- Choosing the right one per route avoids over-paying for freshness you do not need
AI Mentor Explanation
SSR is like a scoreboard operator manually recalculating and repainting the entire display for every single fan who walks up and asks for the score, guaranteeing it is exact to the second but slow if many fans ask at once. SSG is like printing a fixed pamphlet of yesterday's final scores once before the gates open — instant to hand out, but it never reflects anything that happens today. ISR is like printing that same pamphlet but reprinting a fresh batch automatically every ten minutes during play, so most fans get an instantly available copy that is only slightly behind live action. Each strategy trades immediacy against how much repeated work the operator has to redo.
Step-by-Step Explanation
Step 1
Classify the route by freshness need
Decide if the page needs per-request accuracy, rarely-changing content, or occasional refresh.
Step 2
SSR for always-current, personalized pages
Render on every request, fetching live data server-side per visitor.
Step 3
SSG for rarely-changing content
Pre-render at build time; served instantly from a CDN until the next deploy.
Step 4
ISR for periodically fresh, high-scale content
Serve a cached static page and regenerate it in the background after a revalidation window.
What Interviewer Expects
- Clear articulation of when each strategy fits (freshness vs scale/cost tradeoff)
- Understanding that ISR serves stale content while regenerating in the background
- Awareness that SSG content is only as fresh as the last build/deploy
- Real examples: SSR for dashboards, SSG for marketing pages, ISR for product/blog listings
Common Mistakes
- Using SSR for content that rarely changes, wasting server compute on every request
- Assuming SSG content updates automatically without a rebuild or ISR revalidation
- Confusing ISR's stale-while-revalidate behavior with always-fresh SSR
- Not considering CDN caching interplay when choosing a rendering strategy
Best Answer (HR Friendly)
“SSR builds the page fresh every time someone visits, which is great for personalized data but slower under load. SSG builds the page once ahead of time and serves the same fast file to everyone, which is great for content that rarely changes. ISR is a middle ground — it serves that fast pre-built file but automatically refreshes it every so often in the background, so you get speed most of the time and reasonably fresh content without rebuilding the whole site.”
Code Example
// SSR: runs on every request
export async function getServerSideProps() {
const data = await fetch('https://api.example.com/live-price').then((r) => r.json())
return { props: { data } }
}
// SSG: runs once at build time
export async function getStaticProps() {
const data = await fetch('https://api.example.com/about').then((r) => r.json())
return { props: { data } }
}
// ISR: static, but regenerated in the background after 60 seconds
export async function getStaticPropsIsr() {
const data = await fetch('https://api.example.com/products').then((r) => r.json())
return { props: { data }, revalidate: 60 }
}Follow-up Questions
- How does stale-while-revalidate behave under a spike of concurrent requests during ISR regeneration?
- When would you combine SSR and client-side fetching on the same page?
- How do CDNs interact with ISR-generated pages?
- What are on-demand revalidation triggers and when would you use them over a time-based revalidate?
MCQ Practice
1. When is content generated in Static Site Generation (SSG)?
SSG pre-renders HTML during the build pipeline and serves the same file until the next deploy.
2. What is the defining behavior of ISR?
ISR combines static-file speed with periodic background regeneration triggered after a revalidation window.
3. Which rendering strategy best fits a highly personalized, always-current user dashboard?
SSR fetches and renders fresh, request-specific data on every request, which fits personalized live data.
Flash Cards
When does SSR render the page? — On every incoming request, using live server-side data.
When does SSG render the page? — Once at build time; served as a static file until the next deploy.
What does ISR add over SSG? — Automatic background regeneration after a configured revalidation interval.
Core decision axis among the three? — Freshness requirement versus scale/cost of repeated rendering.