Static vs Server Rendering in Next.js: What Marketing Pages Should Use

Should marketing pages use SSG vs SSR in Next.js?

Marketing pages should use static generation, with incremental static regeneration (ISR) for anything a CMS updates. A homepage, pricing page, feature page or blog post shows the same content to every visitor, so rendering it again on every request buys nothing and costs speed.

That's the short verdict we give founders who ask why their Next.js marketing website feels slower than it should. The usual cause is a page that became dynamic by accident, not a framework limit. Server-side rendering (SSR) is a good tool, but it's the right tool for a narrow set of pages: logged-in views, search results and anything that truly changes per request.

What is the difference between static site generation, ISR and SSR?

The three modes differ in when the HTML is built. Static site generation builds it once at deploy time, ISR rebuilds it in the background after a set interval or an on-demand trigger, and SSR builds it fresh on the server for each request.

In the App Router, static is the default. A route only becomes dynamic when it reads request data such as cookies, headers or search params, or when a data fetch opts out of caching. ISR is a revalidate setting on the route or the fetch, plus on-demand revalidation by path or tag when your CMS publishes.

How does the rendering mode affect Core Web Vitals?

Rendering mode mostly affects Largest Contentful Paint, because the browser can't paint anything until the HTML arrives. A static page comes back from the nearest CDN edge almost immediately; an SSR page waits for the server to run, call your CMS and any APIs, and then respond.

Time to first byte is the first part of LCP, so every delay there pushes the largest paint back. Google's documented threshold for a good LCP is 2.5 seconds at the 75th percentile of real visits, and slow server responses eat into that budget before your hero image even starts loading. Static pages also scale for free: a launch-day traffic spike hits cached files, not your server or your CMS API rate limits.

Interaction to Next Paint is a different story. It depends on how much JavaScript runs in the browser, so static HTML alone won't fix it. Our guide to improving INP on Next.js sites covers hydration and client components, and the platform-specific Core Web Vitals fixes cover the rest.

Do AI crawlers and Google need server-rendered pages?

Crawlers need HTML that already contains your content, and both static generation and SSR deliver that. The risk is pages that render their copy only in the browser with client-side JavaScript, because many AI crawlers fetch raw HTML and don't run scripts.

So the SEO argument is not static versus server. It's prerendered versus client-only. A static page is the safest version of server rendering: the HTML is complete, identical every time and served instantly, which is exactly what Googlebot, GPTBot and other crawlers want. We explain the failure mode in detail in server-side rendering for AI crawlers, and the full setup of metadata, sitemaps and schema lives in our Next.js SEO checklist.

When does a marketing site actually need SSR?

A marketing site needs per-request rendering only where the page content depends on who is asking or what they just typed. That's a short list, and most sites have zero or one of these pages.

• Site search results that depend on a query string.
• Logged-in states such as showing an account name or plan in the navigation.
• Real-time data like live inventory, status pages or stock-style figures that can't be a few minutes stale.
• Geo or segment personalization where the entire page changes, not just a banner.
• Preview mode for editors, which should bypass the cache by design.

Even then, you rarely need the whole page dynamic. Keep the shell static and load the personal part separately, either as a small client component, a streamed server component, or through middleware that picks between two prebuilt versions. Newer Next.js releases push this pattern further with cached components and partial prerendering, where a static page streams in one dynamic slot; check the current Next.js docs for the exact configuration in your version.

How do you set up ISR for a CMS-driven Next.js site?

Set up ISR by prebuilding every known page, giving routes a sensible revalidation window, and wiring your CMS to trigger on-demand revalidation when an editor publishes. That gives you static speed with content that updates within seconds.

1. 1

   Prebuild known paths

   Use generateStaticParams on dynamic routes like /blog/[slug] so every published post is built at deploy time.

2. 2

   Pick a fallback window

   Set a revalidate interval, for example an hour, as a safety net in case a webhook fails.

3. 3

   Tag your data

   Tag CMS fetches by content type or document so one publish refreshes only the pages that use it.

4. 4

   Add a publish webhook

   Point your CMS webhook at a route handler that calls revalidateTag or revalidatePath, protected by a secret.

5. 5

   Verify the build output

   Confirm every marketing route is listed as static or ISR, and that no shared layout opts the tree out of caching.

This is how we build CMS-backed sites ourselves, and it pairs well with low-cost hosting, as covered in our guide to hosting Next.js on Cloudflare Workers. For sites with thousands of generated pages, programmatic SEO with static generation explains how to keep build times sane.

Which Next.js rendering mode should each page type use?

Match each page type to the cheapest mode that keeps it accurate. For a typical startup marketing site, that means nearly everything is static or ISR.