Server-Side Rendering (SSR)

SSR sits between static generation and a pure client-rendered single-page app. Unlike SSG, the HTML isn't built once ahead of time — it's generated fresh on every request, which means the page can reflect real-time data (current stock levels, a logged-in user's name, live pricing) without waiting for a rebuild. Unlike client-side rendering, the browser receives a fully formed page on the first response rather than a near-blank HTML shell that JavaScript then populates after loading and executing.

This matters for both SEO and perceived performance: search engine crawlers and AI crawlers reliably see full content immediately, without needing to execute JavaScript first to discover it, and human visitors see meaningful content the moment the page arrives instead of a loading spinner. The cost is server compute — every request does real rendering work, so SSR pages typically need more server capacity and thoughtful caching than pre-built static pages to hold up under high traffic.

Modern meta-frameworks like Next.js blur the line further, letting different routes or even different components on the same page choose SSG, SSR, or client rendering individually, based on how fresh that specific piece of content actually needs to be.