SSR, SSG, ISR: The Rendering Tradeoffs Next.js Makes You Choose

Next.js gives you static generation, server-side rendering, incremental static regeneration, and client-side rendering, and the temptation is to pick one and use it everywhere for consistency. That consistency is exactly what causes either stale marketing pages or needlessly slow dashboards.

• Marketing pages, blog posts, anything rarely changing → static generation, served instantly from the edge.
• Content that updates periodically but not per-request → ISR, with a revalidation window matched to how often it actually changes.
• Personalized or per-user data → server-side rendering, or push it client-side behind a fast static shell.
• Highly interactive, client-owned state (a dashboard filter panel) → client-side rendering inside an otherwise server-rendered page.

The best-performing Next.js apps I've built mix all four strategies within a single page tree — a static shell, a server-rendered personalized section, and a client-rendered interactive widget, each chosen for what it actually needs, not for architectural purity.

Rendering strategy isn't a site-wide decision. It's a per-component decision, and treating it otherwise is how you end up slow or stale.