Server-side rendering vs static generation: which do you need?

If you've been reading about modern web development, you've probably encountered the terms server-side rendering (SSR) and static site generation (SSG). They get discussed a lot, often in confusing ways, so let me try to cut through the jargon.

The old way: everything is dynamic

Traditional web applications, WordPress, Drupal, Laravel apps, generate every page on the fly. A request comes in, the server runs some code, queries a database, assembles HTML, and sends it back. This happens for every visitor, every page load. It works, but it means your server is doing the same work repeatedly, and your visitors wait while it happens.

Static site generation (SSG)

With SSG, your site is built once, at build time, not at request time. A build process generates every page as a plain HTML file. These files are then deployed to a CDN. When a visitor requests a page, the CDN serves the pre-built HTML file. No server-side processing, no database queries, no waiting.

The result is extremely fast page loads. A pre-built HTML file served from a CDN edge location near the visitor loads in milliseconds. It's also inherently secure (there's no dynamic server to exploit) and scales effortlessly (CDNs handle traffic spikes without breaking a sweat).

Tools like Next.js, Eleventy, Gatsby, and Hugo all support static generation. Next.js is particularly clever, it lets you choose SSG on a per-page basis, so your marketing pages can be static while other parts of your site are dynamic.

The trade-off is that content changes require a rebuild. If you publish a new blog post, the site needs to be rebuilt and redeployed for that post to appear. With modern tooling, this typically takes 30 seconds to a couple of minutes, and it happens automatically when you publish in the CMS. But if you need content to appear instantly, stock prices, live scores, real-time inventory, SSG alone isn't sufficient.

Server-side rendering (SSR)

SSR generates pages on the server at request time, similar to the traditional approach. But modern SSR frameworks like Next.js do this more efficiently. They can cache rendered pages, stream HTML progressively, and hydrate the page on the client for interactivity.

SSR makes sense when you need pages that are always up-to-date with the latest data, personalised per user, or dependent on information that isn't known at build time. An e-commerce product page showing real-time pricing and stock levels, a dashboard showing user-specific data, or search results pages, these all benefit from SSR.

The trade-off is that every request requires server processing. You need a server running (not just a CDN), response times are slower than static files, and your hosting costs are higher.

Incremental static regeneration (ISR)

Next.js introduced ISR as a middle ground. Pages are statically generated at build time, but they can be regenerated in the background after a set interval. A visitor always gets a pre-built static page (fast), but the page is periodically refreshed with new data (current). It's an elegant solution for sites that need to be fast but also reasonably up-to-date.

Which do you need?

For most marketing and content sites, SSG is the right choice. The performance is superior, the hosting is simpler and cheaper, and the security benefits are significant. If your content changes a few times a day or less, the brief rebuild time is irrelevant.

For applications with user-specific content, real-time data, or frequent updates, SSR is necessary for at least some pages. The good news is that modern frameworks don't force you to choose one or the other, you can mix SSG and SSR within the same project.

For e-commerce, ISR often hits the sweet spot. Product pages are statically generated for speed but regenerated regularly to reflect price and stock changes.

If you're planning a project and unsure which approach fits, I'm happy to talk through the specifics. Reach me at [email protected].