{"id":23489,"date":"2026-08-12T15:30:37","date_gmt":"2026-08-12T13:30:37","guid":{"rendered":"https:\/\/pagepro.co\/blog\/?p=23489"},"modified":"2026-09-14T10:41:24","modified_gmt":"2026-09-14T08:41:24","slug":"nextjs-rendering-strategies-ssr-ssg-isr-csr","status":"publish","type":"post","link":"https:\/\/pagepro.co\/blog\/nextjs-rendering-strategies-ssr-ssg-isr-csr\/","title":{"rendered":"Next.js Rendering Strategies in 2026: SSR vs SSG vs ISR vs CSR"},"content":{"rendered":"\n

Every Next.js project runs into this decision eventually: which rendering strategy fits which page. Get it wrong and you pay for it in server costs, search visibility, or Core Web Vitals<\/a> \u2014 sometimes all three. <\/p>\n\n\n\n

Next.js 16 changed the calculus by making Cache Components and Partial Prerendering the default, which means the old \u201cpick one strategy for your whole app\u201d framing no longer applies. <\/p>\n\n\n\n

Here’s how SSR, SSG, ISR, and CSR actually differ in 2026, when each is the right call, and how Cache Components let you combine them on a single page.<\/p>\n\n\n\n

The Four Rendering Strategies at a Glance<\/h2>\n\n\n\n
Strategy<\/strong><\/td>When HTML Is Built<\/strong><\/td>SEO Impact<\/strong><\/td>Typical Cost<\/strong><\/td>Best For<\/strong><\/td><\/tr>
SSR<\/td>On every request, server-side<\/td>Strong \u2014 full HTML at request time<\/td>Higher \u2014 server computes per visit<\/td>Personalized or per-request data: search results, checkout<\/td><\/tr>
SSG<\/td>At build time<\/td>Strong \u2014 full HTML pre-rendered<\/td>Lowest \u2014 served from CDN<\/td>Marketing pages, docs, rarely-changing content<\/td><\/tr>
ISR<\/td>At build time, then regenerated on an interval or on demand<\/td>Strong \u2014 same as SSG<\/td>Low \u2014 regenerates only when needed<\/td>Blogs, product catalogs, content that changes but not per-second<\/td><\/tr>
CSR<\/td>In the browser, after JS loads<\/td>Weak \u2014 content arrives after JS executes<\/td>Lowest server cost, highest client cost<\/td>Authenticated dashboards, internal tools where SEO doesn’t matter<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The pattern worth internalizing: SSR, SSG, and ISR all send complete HTML, so search engines index them the same way. CSR is the outlier \u2014 a crawler has to execute JavaScript before there’s anything to read, which is slower and less reliable at scale. This also shows up in Core Web Vitals: Interaction to Next Paint (INP), a confirmed Google ranking signal, penalizes heavy client-side JavaScript execution, which is exactly what CSR depends on.<\/p>\n\n\n\n

\"Infographic<\/figure>\n\n\n\n

Server-Side Rendering (SSR)<\/span><\/h3>\n\n\n\n

SSR generates HTML on the server for every request. The visitor \u2014 and the crawler \u2014 gets complete, current markup immediately, and the page can reflect data that’s specific to that request: a logged-in user, a live price, a search query.<\/p>\n\n\n\n

In the App Router, a route becomes dynamic (SSR) as soon as it reads request-time data \u2014 cookies, headers, search params, or an explicitly uncached fetch:<\/p>\n\n\n\n

\/\/ app\/products\/[id]\/page.tsx\nasync function getProduct(id: string) {\n\u00a0 const res = await fetch(`https:\/\/api.example.com\/products\/${id}`, {\n\u00a0 \u00a0 cache: 'no-store',\n\u00a0 });\n\u00a0 return res.json();\n}\n\nexport default async function ProductPage({\n\u00a0 params,\n}: {\n\u00a0 params: { id: string };\n}) {\n\u00a0 const product = await getProduct(params.id);\n\u00a0 return <div>{product.name}<\/div>;\n}<\/code><\/pre>\n\n\n\n
The tradeoff: the server does work on every visit, so cost and latency scale with traffic. Use SSR when data genuinely can’t be cached \u2014 not as a default.<\/p>\n\n\n\n
Static Site Generation (SSG)<\/span><\/h3>\n\n\n\n
SSG generates HTML once, at build time<\/a>, and serves it from a CDN. There’s no per-request server computation, so it’s the fastest and cheapest option to run \u2014 Time to First Byte is close to minimal, and the attack surface shrinks along with the infrastructure.<\/p>\n\n\n\n
In the App Router, this is simply a fetch with default caching \u2014 no extra configuration needed:<\/p>\n\n\n\n
async function getPosts() {\n\u00a0 const res = await fetch('https:\/\/api.example.com\/posts'); \/\/ cached at build\n\u00a0 return res.json();\n}\n\nexport default async function BlogPage() {\n\u00a0 const posts = await getPosts();\n\u00a0 return <PostList posts={posts} \/>;\n}<\/code><\/pre>\n\n\n\n
The limitation: content is frozen until the next build. On a site with thousands of pages, or content that changes often, that means either long build times or stale pages \u2014 which is exactly what ISR exists to fix.<\/p>\n\n\n\n
Incremental Static Regeneration (ISR)<\/span><\/h3>\n\n\n\n
ISR keeps SSG’s speed but regenerates individual pages in the background, either on a fixed interval or on demand, without rebuilding the whole site. It’s the right default for most content-driven pages: fast to serve, cheap to run, and never more than one revalidation cycle out of date.<\/p>\n\n\n\n
async function getPosts() {\n\u00a0 const res = await fetch('https:\/\/api.example.com\/posts', {\n\u00a0 \u00a0 next: { revalidate: 3600 }, \/\/ regenerate at most once per hour\n\u00a0 });\n\u00a0 return res.json();\n}<\/code><\/pre>\n\n\n\n
For updates triggered by an event \u2014 a CMS publish, an inventory change \u2014 call revalidatePath() or revalidateTag() from a Server Action or webhook handler instead of waiting on the interval. That’s the on-demand half of ISR, and it’s what makes it viable for e-commerce and news, not just blogs.<\/p>\n\n\n\n
Client-Side Rendering (CSR)<\/span><\/h3>\n\n\n\n
CSR sends a minimal HTML shell and builds the page in the browser with JavaScript. It’s the right model for authenticated, highly interactive surfaces where SEO is irrelevant \u2014 dashboards, admin panels, internal tools \u2014 because the user stays in one long session and speed-to-first-paint matters less than responsiveness after that.<\/p>\n\n\n\n
'use client';\nimport { useEffect, useState } from 'react';\n\nexport default function Dashboard() {\n\u00a0 const [data, setData] = useState(null);\n\n\u00a0 useEffect(() => {\n\u00a0 \u00a0 fetch('\/api\/dashboard')\n\u00a0 \u00a0 \u00a0 .then((r) => r.json())\n\u00a0 \u00a0 \u00a0 .then(setData);\n\u00a0 }, []);\n\n\u00a0 return data ? <DashboardView data={data} \/> : <Spinner \/>;\n}<\/code><\/pre>\n\n\n\n
The cost: content only exists after JavaScript executes, which is slower and less crawler-friendly than the alternatives, and heavy client-side execution is a direct driver of poor INP scores. <\/p>\n\n\n\n
CSR behind a login wall is a reasonable, deliberate choice. CSR as the default rendering strategy for a public, SEO-dependent page usually isn’t.<\/p>\n\n\n\n
What Changed in Next.js 16: Cache Components and Partial Prerendering<\/h2>\n\n\n\n
Through Next.js 15, a route was either fully static or fully dynamic \u2014 there was no in-between. <\/p>\n\n\n\n
Next.js 16 removes that constraint with Cache Components, which complete the Partial Prerendering (PPR) model first introduced in 2023: a single route can serve a static, pre-rendered shell immediately while genuinely dynamic parts stream in separately, without holding up the rest of the page.<\/p>\n\n\n\n
Enable it with one flag:<\/p>\n\n\n\n
\/\/ next.config.ts\nimport type { NextConfig } from 'next';\n\nconst nextConfig: NextConfig = {\n\u00a0 cacheComponents: true,\n};\n\nexport default nextConfig;<\/code><\/pre>\n\n\n\n
In practice, this means wrapping the request-time-dependent part of a page in Suspense, while everything else stays static:<\/p>\n\n\n\n
export default function ProductPage({ params }: { params: { id: string } }) {\n\u00a0 return (\n\u00a0 \u00a0 <div>\n\u00a0 \u00a0 \u00a0 <ProductInfo id={params.id} \/> {\/* static shell *\/}\n\u00a0 \u00a0 \u00a0 <Suspense fallback={<InventorySkeleton \/>}>\n\u00a0 \u00a0 \u00a0 \u00a0 <LiveInventory id={params.id} \/> {\/* streamed in, dynamic *\/}\n\u00a0 \u00a0 \u00a0 <\/Suspense>\n\u00a0 \u00a0 <\/div>\n\u00a0 );\n}<\/code><\/pre>\n\n\n\n
This is why the SSR-vs-SSG framing<\/a> is incomplete on its own in 2026: on a single product page, the description and layout can be static (SSG\/ISR), while live inventory or a personalized recommendation streams in dynamically (SSR-like), all without the old all-or-nothing tradeoff. <\/p>\n\n\n\n
The strategies above are still the building blocks \u2014 Cache Components just mean you’re no longer forced to pick exactly one per route.<\/p>\n\n\n\n
How to Choose: A Decision Framework<\/h2>\n\n\n\n
Page Type<\/strong><\/td>Recommended Strategy<\/strong><\/td>Why<\/strong><\/td><\/tr>
Marketing \/ landing pages<\/td>SSG (or ISR if content is CMS-managed)<\/td>Content rarely changes; maximum speed at the lowest cost<\/td><\/tr>
Blog \/ documentation<\/td>ISR<\/td>Updates without full rebuilds; still fully static between revalidations<\/td><\/tr>
E-commerce product pages<\/td>ISR + Cache Components for live inventory\/price<\/td>Catalog data is stable; inventory and price need to stay current<\/td><\/tr>
Search results \/ filtered listings<\/td>SSR<\/td>Query-specific output isn’t cacheable per fixed URL<\/td><\/tr>
Checkout \/ cart<\/td>SSR, or CSR behind auth<\/td>Per-user, per-session; no SEO value to preserve<\/td><\/tr>
Authenticated dashboards<\/td>CSR<\/td>No SEO requirement; rich interactivity is the actual point<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Default to ISR for anything content-driven unless there’s a specific reason not to. <\/p>\n\n\n\n
SSR should be the exception you reach for when data truly can’t be cached \u2014 not the starting point \u2014 because it’s the only one of the four whose cost scales directly with traffic.<\/p>\n\n\n\n
Applying This to Common Page Types<\/span><\/h3>\n\n\n\n
The framework above is easy to nod along to in the abstract. It gets more useful once you attach it to three architectures almost every team ends up building \u2014 because each one has a natural rendering fingerprint, and fighting it is where most of the wasted server spend actually comes from.<\/p>\n\n\n\n
\"Dark-themed<\/figure>\n\n\n\n
The marketing site: mostly static, and deliberately boring about it<\/h4>\n\n\n\n
A corporate or marketing site should be one of the cheapest, fastest things you run \u2014 the homepage, service pages, and blog have no business paying SSR’s per-request tax, because almost nothing on them is actually per-request. SSG or ISR carries essentially the whole site.<\/p>\n\n\n\n
\n
Common mistake:<\/strong> a contact form or personalized CTA banner convinces a team to make the entire page<\/em> dynamic. The fix isn’t SSR for the route \u2014 it’s a small client component dropped into an otherwise static page, so one form doesn’t tax every visitor who never touches it.<\/p>\n<\/blockquote>\n\n\n\n
The e-commerce catalog: static bones, live nerve endings<\/h4>\n\n\n\n
A product page is really two pages wearing one URL: the description, images, and reviews that barely change, and the stock count or price that can change by the minute. ISR handles the first half; Cache Components stream in the second half as a live “hole” in an otherwise cached shell. <\/p>\n\n\n\n
Cart and checkout don’t belong in this conversation at all \u2014 they’re per-session, carry zero SEO value, and are better handled by SSR or CSR without dragging the rest of the site’s rendering strategy into the decision.<\/p>\n\n\n\n
The internal dashboard: where CSR finally gets to be the right answer<\/h4>\n\n\n\n
Everywhere else in this article, CSR is the strategy you reach for reluctantly. An admin panel or analytics dashboard is the exception, not a compromise: nobody needs to find it on Google, users stay logged in for long stretches, and the interactivity is the entire product. <\/p>\n\n\n\n
The slow-first-paint, weak-SEO tradeoffs that rule CSR out for a marketing page simply don’t apply behind a login wall \u2014 so this is the one place a full client-rendered app is the deliberate, correct default.<\/p>\n\n\n\n
Quick self-check \u2014 is your current setup fighting its own architecture?<\/strong><\/p>\n\n\n\n