5 questions found
What are the three main rendering strategies available in Next.js, and what does each one mean?
Beginner
Server side rendering, called SSR, generates the page fresh on every request. Static site generation, called SSG, generates the page once at build time and reuses it for every visitor. Incremental static regeneration, called ISR, generates a page once but automatically refreshes it after a set amount of time, combining the speed of static pages with reasonably fresh content.
// SSG: fetched once at build time
// SSR: fetched fresh on every request
// ISR: fetched once, then refreshed periodically
const res = await fetch(url, { next: { revalidate: 3600 } });
Real-world example
A news website uses SSR for its live sports scores that must always be current, SSG for its rarely changing about page, and ISR for its article pages that update occasionally but do not need to be rebuilt on every single visit.
Common follow-ups: How do you choose the right rendering strategy for a specific page?;Can a single application use all three rendering strategies for different pages?
Caching;On-Demand Revalidation Strategies
What are the main benefits of static site generation, and when is it the best choice?
Beginner
Static site generation produces the fastest possible loading pages since the HTML is already fully built and can be served instantly from a content delivery network, making it ideal for content that does not change often, like marketing pages, documentation, or blog posts that are not updated many times a day.
// Server component with no dynamic data source
// automatically becomes statically generated
export default async function AboutPage() {
return <h1>About Our Company</h1>;
}
Real-world example
A company's about page and pricing page load almost instantly for every visitor around the world since they are statically generated once and served directly from a content delivery network.
Common follow-ups: What happens if you need to update statically generated content after it has already been built?;Is static site generation suitable for personalized content?
Deployment;On-Demand Revalidation Strategies
When would server side rendering be the better choice over static site generation or incremental static regeneration?
Intermediate
Server side rendering is the right choice when a page's content must be completely up to date on every single visit and cannot tolerate any staleness, such as a live stock ticker, a personalized dashboard showing a specific user's private data, or a page whose content depends heavily on cookies or request headers.
// Using cache: 'no-store' forces server side rendering behavior
const res = await fetch('https://api.example.com/stock-price', { cache: 'no-store' });
Real-world example
A financial trading platform uses server side rendering for its live stock price page, ensuring every visitor always sees the current price rather than a potentially outdated cached version.
Common follow-ups: Does server side rendering have a performance cost compared to static pages?;How do you combine server side rendering with streaming for a better experience?
Loading UI & Streaming with Suspense;Data Fetching
How does incremental static regeneration let you get the benefits of both static pages and fresh content?
Intermediate
Incremental static regeneration serves the existing fast, cached static page to visitors while a new version is being generated in the background after the revalidation period passes, so the current visitor never waits for a rebuild, and the next visitor after that automatically sees the updated content once it is ready.
// This page will regenerate at most once every 300 seconds
const res = await fetch('https://api.example.com/products', {
next: { revalidate: 300 }
});
Real-world example
A large e-commerce catalog uses incremental static regeneration so product pages stay fast for every visitor while automatically refreshing their prices and stock levels every few minutes in the background.
Common follow-ups: What happens to a visitor while a page is being regenerated in the background?;How does incremental static regeneration differ from on-demand revalidation?
On-Demand Revalidation Strategies;Caching
How would you design a rendering strategy for a large application with a mix of static marketing pages, semi dynamic product pages, and fully personalized account pages?
Advanced
You would use static site generation for the marketing pages since they rarely change, incremental static regeneration for product pages that update periodically but benefit from fast cached loading, and server side rendering or fully dynamic client fetching for personalized account pages that depend entirely on the specific logged in user.
// Marketing page: fully static
// Product page: ISR with revalidate
fetch(url, { next: { revalidate: 600 } });
// Account page: dynamic, no caching
fetch(url, { cache: 'no-store' });
Real-world example
A large online retailer builds its marketing pages as fully static, its product catalog with incremental static regeneration for freshness without sacrificing speed, and its personalized account dashboard with fully dynamic rendering tailored to each specific customer.
Common follow-ups: How do you measure whether the chosen rendering strategy is actually meeting performance goals?;What tools help visualize which rendering strategy each page in a large app is using?
Web Vitals & Performance Monitoring;Caching