These are the three main strategies for when a page's HTML is generated. Choosing the right one per page balances freshness, performance, and server cost.
() {
posts = (, { : }).( r.());
;
}
The page is pre-rendered to static HTML at build and cached on a CDN. Fastest possible delivery, but the content is frozen until the next build. Best for content that rarely changes: marketing pages, docs, blog posts.
// HTML generated FRESH on every request
export default async function Page() {
const data = await fetch("...", { cache: "no-store" }).then(r => r.json());
return <Dashboard data={data} />;
}
The server renders the page per request, so data is always current — at the cost of slower responses and server load on every visit. Best for personalized or always-fresh data: dashboards, account pages, search results.
// Static, but automatically rebuilt in the background every N seconds
export const revalidate = 60; // regenerate at most once per 60s
export default async function Page() {
const products = await fetch("...", { next: { revalidate: 60 } }).then(r => r.json());
return <Products items={products} />;
}
ISR serves static HTML (fast, CDN-cached) but revalidates it in the background on a schedule — so you get static performance with periodically fresh data, without rebuilding the whole site. Best for content that changes occasionally: product listings, news, leaderboards.
Speed Freshness Server cost Use for
SSG fastest build-time only none docs, marketing
SSR slower always fresh every request dashboards, personalized
ISR fast every N seconds occasional catalogs, news
In the App Router you pick these per-fetch via cache options (force-cache = SSG, no-store = SSR, revalidate = ISR) rather than special functions.
Understanding the trade-off — static is fastest but stale, SSR is fresh but costly, ISR balances both — lets you optimize each page for the right mix of performance and data freshness.