What Is SSR: why servers render pages instead of browsers

BasicsFrontendWebPerformance

What SSR is and why not all pages load the same way

Open any modern website — and you see text, images, buttons. Everything on screen. But if you look under the hood, some sites arrive fully formed, with content and structure intact. Others arrive as an empty shell with a set of instructions: “okay browser, build this, do that, and eventually the user will see something.”

SSR (Server-Side Rendering) is when the server builds the full HTML page before sending it to you. You get ready-made content immediately — the browser doesn’t need to construct anything from scratch.

The opposite approach is CSR (Client-Side Rendering), where the browser gets an empty HTML page plus JavaScript code that builds the entire interface itself.

The problem: why SPA isn’t always good enough

For the past 10-15 years, SPA (Single Page Application) has been fashionable. The idea is elegant: load the app once, then everything works fast with no full-page reloads. React, Vue, Angular — they all follow this model.

But there are three problems SPA doesn’t solve:

1. Slow first paint. When a user visits an SPA site, they first see an empty screen or a loading spinner. The browser downloads a JavaScript bundle (sometimes several megabytes), then executes it, then builds the DOM, and only then does content appear. On fast internet that’s a second. On mobile 3G it’s five to ten.

2. SEO. Search engine bots don’t always handle JavaScript well. Google is getting better, but Bing, Yahoo, and social media link previews are not always reliable. If content is generated on the client side, a bot might literally see nothing.

3. Accessibility. People with slow devices, old phones, or those who have disabled JavaScript for battery or privacy reasons — they get a blank page.

SSR solves all three: the server sends ready-made HTML, content is visible immediately, SEO works out of the box, and even the weakest phone shows text right away.

How this works in plain language

SSR — the server builds HTML

  1. You open a website.
  2. The browser sends a request to the server.
  3. The server builds a complete HTML page with content.
  4. It sends it back.
  5. You see text and images instantly.
  6. Then JavaScript “hydrates” the page — it adds interactivity: clicks, forms, animations.
Browser → request → Server → generates HTML → Browser displays content → JavaScript adds interactivity

What comes from the server:

<html>
  <body>
    <h1>Hello, ITAcademy!</h1>
    <p>The server generated this text.</p>
  </body>
</html>

CSR — the browser builds HTML

  1. You open a website.
  2. The browser receives an empty HTML shell and a large JavaScript file.
  3. JavaScript executes in the browser.
  4. JavaScript builds the HTML structure.
  5. Finally you see the content.
Browser → request → Server sends HTML shell + JS bundle →
JS downloads → executes → builds DOM → user finally sees content

What comes from the server:

<html>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>  <!-- the entire site lives here -->
  </body>
</html>

SSG — pages are built ahead of time

There is a third approach: Static Site Generation. Pages are generated once during the build step and stored as plain HTML files. When someone requests a page, the server just serves the file. This is the fastest option but doesn’t work for everything (personal dashboards, for example).

Comparison: when to pick what

SSRCSR (SPA)SSG
First renderFast (ready HTML)Slow (waits for JS)Instant (ready file)
SEO✅ Excellent⚠️ Depends on the bot✅ Excellent
Interactivity✅ After hydration✅ Right away✅ After hydration
Server loadHigher (generates every request)Lower (only serves JS)Minimal (serves files)
Personalization✅ Per-user pages✅❌ One page for everyone
Admin panels / SaaS✅✅❌
Blogs / docs✅✅✅ (best option)

When SSR is the best choice

SSR is ideal when:

  • SEO is critical: e-commerce, news sites, blogs.
  • Content is dynamic but not personalized: product pages, articles, catalogs.
  • Audience uses diverse devices: from old phones to powerful laptops. SSR levels the playing field: everyone sees content at the same speed.
  • First render speed matters: the user should see something immediately, even on a slow connection.

When SSR is not needed

Skip SSR when:

  • The app is fully internal: admin panels, CRMs, team dashboards where only logged-in people go — SEO doesn’t matter here.
  • Content is heavily personalized per user: if the server has to make 10 API calls just to build the page, TTFB becomes large.
  • The team isn’t ready for extra infrastructure: SSR needs a server that generates HTML. That is more complex than just serving static files through a CDN.

Common mistakes when working with SSR

1. Hydration breaks

If the HTML from the server differs from what JavaScript builds on its own, React (or another framework) discards everything and starts over. That is a hydration mismatch. The result: content flickers or interactivity doesn’t work.

2. Too many API calls on the server

The server generates a page for every request. If building that page requires 20 API calls — the page will be slow. Solutions: caching, data aggregation, or SSG with regeneration.

3. Confusing SSR with SSG

SSG generates pages ahead of time during the build. SSR regenerates on every request. If the content doesn’t change often, SSG is faster and cheaper.

4. Ignoring server-side errors

In an SPA, a JavaScript error shows in the browser console. In SSR, a server error can return an empty page or a 500 error. You need proper error handling in the server code.

Conclusion / action plan

SSR is not magic and not a requirement. It’s a tool that makes a site faster and more accessible for those who need it.

Here is what to do next:

  1. Look at your site: do you use SSR, CSR, or SSG?
  2. Check speed with PageSpeed — pay attention to LCP (when the main content appears).
  3. If the site needs better SEO or a faster first render — try Next.js (for React) or Nuxt (for Vue).
  4. For content pages (blogs, documentation, posts) consider SSG — it’s even faster than SSR.
  5. Don’t rebuild everything at once. Start with one page and compare metrics.

Not every site needs SSR. But if content matters and needs to be found through search — SSR can be the simplest way to make a site better without a full rewrite.

Quick checklist

  • Identify which rendering type your site uses (SPA / SSR / SSG / mixed).
  • Run a PageSpeed or Lighthouse check — look at LCP and TTFB scores.
  • Try disabling JavaScript in your browser and opening your site — is the content still there?
  • For your next project, try Next.js or Nuxt and see how SSR works in practice.
  • Compare the load time of an SSR page versus an SPA page on a slow mobile connection.

Prompt Pack: pick a website rendering strategy

I am building a website and want to understand whether I should use SSR for my project. Input data: - website type (landing page, e-commerce, interactive app, blog); - how important SEO is; - audience profile (fast internet / mobile devices / regions with slow connectivity); - which framework is in use (React, Vue, Svelte, other). Return the result in this format: 1. what SSR is and what alternatives exist (SPA, CSR, SSG, ISR); 2. comparison: when SSR is better, when it is worse; 3. how to pick the optimal rendering strategy; 4. a simple SSR example without a framework; 5. common mistakes when implementing SSR.