Server-Side Rendering vs Static Site Generation

Server-side rendering (SSR) builds a page's HTML on the server each time someone requests it. Static site generation (SSG) builds the HTML once, ahead of time, and serves the same file to everyone. Both send ready-made HTML to the browser, which is good for speed and search. The difference is when the work happens, and that decides how fresh, personal and fast each page can be. This comparison is part of our website design best practices guide.

When the HTML is built

With server-side rendering, a request arrives, the server fetches the data the page needs, fills in the template and sends back the finished HTML. The next request repeats the work, unless the result is cached.

With static site generation, the work happens before anyone visits. During a build, the site produces one HTML file per URL. Those files can be copied to a CDN, so each visitor gets a file from a server near them, with nothing to compute.

There's a third pattern worth knowing: client-side rendering, where the server sends a mostly empty page and JavaScript in the browser builds the content. The Chrome team's guide on web.dev notes that client-side rendering can be hard to make and keep fast on phones, and encourages developers to consider server-side or static rendering over a full rehydration approach.

Speed for visitors

Both approaches send HTML the browser can paint straight away, so both tend to give a fast First Contentful Paint. They differ in the step before that.

A static file only has to be sent, which is why web.dev describes static rendering as giving a consistently fast Time to First Byte. Server-side rendering has to generate the page first, and that time adds to Time to First Byte, which in turn delays Largest Contentful Paint. Caching the rendered HTML closes much of the gap.

Neither approach fixes heavy JavaScript. If a page ships a large bundle that must run before buttons work, responsiveness suffers either way. Our website speed test guide shows how to see where the time goes.

Keeping content up to date

Server-side rendering is always current, because every response is built from the latest data. Publish a change and the next visitor sees it.

Static generation is only as current as the last build. For a site with a few dozen pages that change a few times a week, rebuilding on each publish is simple. For thousands of pages, full rebuilds get slow. Web.dev notes that static rendering must generate a file for every URL ahead of time, which can be hard when there are very many pages.

Frameworks now soften this. Next.js, one of the platforms we build on, offers incremental static regeneration. It serves static pages, then rebuilds a page in the background after a set time or when your content system says it changed.

Personal and live content

Some pages can't be the same for everyone: an account dashboard, a basket, search results, or stock levels that change by the minute. Static files can't know who is asking, so these pages need server-side rendering, or a static shell that fetches the live part in the browser.

Most marketing pages don't fall into this group. A service page, a case study or a blog post reads the same for every visitor. Rendering it again on every request adds server cost and Time to First Byte for no visible benefit.

Search engines and crawlers

For search, the two approaches are close to equal, because both put the full content in the HTML response. That's what matters most.

Google can render JavaScript, but its documentation explains that pages wait in a rendering queue, sometimes for seconds and sometimes longer, and that rendering can fail. It calls server-side or pre-rendering a great idea because it makes sites faster for users and crawlers, and because not all bots can run JavaScript. Google also now describes dynamic rendering, serving crawlers a different version, as a workaround rather than a long-term solution.

Whichever you choose, return real HTTP status codes. A missing page should send a 404, not a friendly page with a 200 status.

Accessibility and resilience

Rendering choices affect accessibility more than they first appear to. HTML that arrives complete can be read by a screen reader the moment it loads, and links work even if a script fails or loads slowly.

The risk is the gap between looking ready and being ready. Web.dev warns that pages rendered on the server and then taken over by JavaScript can look interactive but can't respond until the scripts have run. For someone using a keyboard or a switch device, a button that does nothing is a dead end. Use real links and buttons that work before scripts load where you can.

Client-side navigation needs care too. When a framework swaps page content without a full load, we update the document title to describe the new page, which WCAG's Page Titled criterion asks for, and move focus to the new main heading so the change isn't silent. Status updates should be announced, as WCAG's Status Messages criterion describes.

Which should you choose?

For most business websites, static generation is the better default. Service pages, case studies and articles are the same for every visitor, and prebuilt pages are fast, cheap to serve and simple to cache. Refresh them on publish, or use incremental regeneration if there are many pages.

Use server-side rendering for the pages that genuinely need request-time data, and keep those pages lean. Most modern frameworks let you mix the two on one site, so this is a page-by-page decision, not a site-wide one.

Where the content lives matters as much as how it's rendered, which we cover in what a headless CMS is. Platform choice is a separate question, covered in our post Next.js vs Webflow vs Framer. If you'd rather have the architecture planned for you, our in-house web team designs and develops sites with performance and SEO foundations built in.

Both are rendering approaches, not products. Criteria were set before the verdict, and each approach is judged on the same six criteria using web.dev, Google Search Central and framework documentation.