Server-side rendering (SSR)

Server-side rendering means the page's HTML is assembled fresh on the server every time someone asks for it. The browser receives a complete document it can paint immediately, then JavaScript "hydrates" it to make it interactive. This differs from client-side rendering, where the browser downloads a near-empty shell and builds the page itself.

How it works

When a request hits an SSR route, the server runs your page code, fetches whatever data the page needs, and returns finished HTML. In Next.js, a route renders this way when it depends on per-request data — cookies, headers, search params, or a database read that must be current. Reading any of those request-time values (outside a streaming boundary) opts the route into dynamic rendering. The framework runs the component on the server, streams the markup, and ships a small amount of JavaScript to wire up interactivity afterward.

This per-request behavior is part of the broader App Router rendering model, where each route can be static, dynamic, or a mix of both.

The trade-off is freshness versus speed. Because the page is built per request, every visitor can get current data, but the server does work each time. That contrasts with static site generation, where HTML is built once at deploy time, and with incremental static regeneration, which rebuilds static pages on a schedule. Choosing among them is the core of static versus dynamic rendering.

Why it matters for B2B sites

For B2B and SaaS marketing pages, SSR's main win is that crawlers and AI answer engines receive real content in the initial HTML, not a blank shell that needs JavaScript to fill. That makes pages reliably indexable and quotable. In our experience, most marketing pages don't actually need per-request rendering — they're better served static or regenerated, which is faster and cheaper. SSR earns its place on genuinely dynamic pages: a logged-in dashboard, a personalized quote, or a page that reads live data.

The practical guidance in our Next.js for marketing sites guide is to default to static rendering and reach for SSR only where the data must be fresh on every request. That keeps Core Web Vitals tight while preserving the dynamic behavior the page genuinely needs.

FAQ

Is server-side rendering the same as static site generation?

No. SSR builds the HTML fresh on the server for each request, so every visitor can get current data. Static site generation builds the HTML once at deploy time and serves the same file to everyone, which is faster and cheaper but not per-request fresh.

Does SSR help with SEO and AI search?

Yes, in the sense that it puts real content in the initial HTML. Crawlers and AI answer engines can read and quote the page without executing client-side JavaScript. For purely static content, static rendering gives the same indexability benefit with better performance.

When should I use SSR in Next.js instead of static rendering?

Use SSR only when a page depends on data that must be current for each request — reading cookies, headers, search params, or a live database value. For most marketing pages, default to static rendering or incremental static regeneration, and reserve SSR for genuinely dynamic pages like a logged-in dashboard or a personalized quote.