Static Generation vs SSR: Which for a Marketing Site?

Pick the wrong rendering strategy and you either pay too much for hosting, ship slow pages, or stop being able to update content without a deploy. Next.js gives you four options — SSG, SSR, ISR, and edge — and most teams reach for SSR by default because it feels safer. It is not. For a marketing site, SSR is usually the wrong call.

This guide lays out a decision tree you can apply on any project. It is opinionated because the wrong defaults compound. For the broader Next.js context, see the marketing sites pillar.

What does each rendering strategy actually mean?

Next.js 15's App Router exposes four rendering modes. They are not mutually exclusive — different pages in the same app can use different modes. The choice is made per route, usually with a single line of configuration.

• Static Site Generation (SSG) — HTML rendered at build time, served from CDN, zero per-request server work, response time <100ms
• Server-Side Rendering (SSR) — HTML rendered on every request, response time 200-800ms, lets you personalize per user
• Incremental Static Regeneration (ISR) — SSG but the HTML revalidates on a schedule (e.g. every 60 seconds) or on demand
• Edge runtime — code runs at the CDN edge (Vercel Edge, Cloudflare Workers), 10-50ms cold start, useful for geo/auth middleware

Why is SSG the default answer for marketing pages?

A marketing page — your home page, services pages, industry landing pages, blog posts — has the same HTML for every visitor on every request. Rendering that HTML on every request (SSR) is pure waste. Render it once at build time, push it to a CDN, and serve it in 50ms from a city near the visitor.

Concretely: a Next.js services page rendered via SSG and served from Vercel's CDN responds in 30-80ms globally. The same page on SSR with a database lookup responds in 250-600ms, depending on origin region and database latency. The SSG version also costs nothing at scale because CDN egress is essentially free, while SSR scales with serverless function invocations.

When should you use ISR instead of plain SSG?

Incremental Static Regeneration is the right call when content updates more often than you deploy. Three common cases on marketing sites: the blog index that needs a new post to appear without redeploying, a case-studies page where new entries land from a CMS, and a pricing page that the founder edits in production.

• Blog index page — revalidate: 300 (5 minutes), new posts from CMS show up automatically
• Case studies index — revalidate: 600 (10 minutes), or on-demand revalidation via webhook from CMS
• Pricing page — revalidate: 60 (1 minute) if pricing is fluid; or use on-demand revalidation when the CMS publishes
• Author/team pages — revalidate: 3600 (1 hour), bios change but rarely
• Stats or counter pages — revalidate: 86400 (1 day) if numbers come from analytics

ISR's killer feature is on-demand revalidation via res.revalidate() or revalidatePath(). When your CMS publishes a new blog post, it can hit a Next.js webhook that revalidates the affected pages in seconds — you get the freshness of SSR with the speed of SSG.

When does SSR actually win?

SSR earns its keep when the HTML genuinely differs per request. On a marketing site this is rare. The honest list is short: pages that show user-specific data (account dashboards, gated content), pages with personalized content based on cookies/geo (only when the personalization cannot be done client-side), and pages with content that changes faster than ISR's minimum revalidate window.

• Customer portal or dashboard — SSR with auth, every render is per-user
• Personalized landing pages by ad campaign — SSR or middleware-based variant routing
• Real-time inventory or availability pages — SSR if the data changes minute-by-minute
• Geo-personalized homepages — middleware + edge runtime is usually a better choice than SSR
• A/B testing experiments — middleware + cookie at the edge, not full SSR

Note that several common 'SSR use cases' are actually solvable with client-side fetching after the initial static render. A 'logged-in welcome banner' on an otherwise-static homepage should be a client component that fetches the user — not a reason to SSR the whole page. SSR the small thing, not the wrapper.

What does the decision tree look like?

Here is a flow you can apply on any Next.js project. Answer the questions in order and you land on the right rendering mode in under a minute.

• 1. Does the page show different content per user (auth, personalization)? → SSR or middleware
• 2. Does the page need to update faster than your deploy cadence? → ISR with appropriate revalidate or on-demand revalidation
• 3. Does the page depend on real-time data (inventory, availability)? → SSR (or fetch client-side after SSG render)
• 4. Does the page need geo-routing or A/B testing? → Edge middleware, keep the rendered page SSG
• 5. None of the above? → SSG (the default, and the right answer for most marketing pages)

What does the cost difference look like at scale?

Cost is the unsexy reason SSG wins. On Vercel's pricing as of 2026: SSG pages cost ~$0.40 per million CDN requests. SSR pages cost ~$2 per million function invocations plus compute time (a 200ms function call at 1024MB is ~$0.0000008, so 10M SSR requests is ~$8 in compute on top of bandwidth).

For a site doing 500,000 monthly visitors averaging 2 pages each (1M page views), the bill difference is small in absolute terms — maybe $5-$15/month — but the SSR version also gets slower as it scales (origin region constraints) while the SSG version stays at 50ms forever. Multiply the differential by 10x traffic and the gap matters.

How does Next.js 15 default behavior affect this?

Next.js 15 made SSG the default for App Router pages. A page is automatically static unless it uses dynamic functions (cookies(), headers(), searchParams) or fetches with no-store. This is the right default — it means new pages start fast and you have to opt into SSR.

The gotcha: it is easy to accidentally opt out of static rendering. Reading cookies() in a layout file makes every page under that layout SSR. Calling headers() inside a shared component does the same. We run a build-time check that prints the rendering mode of every route — if a page that should be static showed up as 'dynamic,' we hunt down the source. Partial Prerendering (PPR) in Next.js 15 helps by letting you stream the dynamic shell separately, but you still want most of the page static.

What does this look like in code?

The configuration is intentionally minimal. Three lines control the rendering mode for any App Router page.

• Default (SSG) — no configuration, just export the page
• Force static — `export const dynamic = 'force-static'`
• ISR — `export const revalidate = 60` (seconds)
• SSR — `export const dynamic = 'force-dynamic'` or use cookies()/headers()
• On-demand revalidation — call `revalidatePath('/blog')` from a webhook handler

How do you ship this in production?

The rendering strategy decision is part of the broader Next.js production checklist. For a typical 25-30 page marketing site, expect ~24 SSG pages, ~5 ISR pages (blog index, case studies index, pricing, locations, services index), and 0-2 SSR pages (only if you have a gated section). That distribution is what 95/4/1 looks like in practice.

If you are stuck on whether a specific page needs SSR or ISR, book a strategy call and we will walk through your routes. For the full production setup, see our website design service.