Demystifying Rendering Modes - SPA/CSR, SSR, SSG, OMG 😱

Web development has been around for a while — more than 35 years, in fact. Sir Tim Berners-Lee made the first successful communication between an HTTP client and a server back in the autumn of 1989. That first website was nothing more than a static page explaining how to create web pages and what hypertext was. A few years later, in '93, dynamic websites arrived with CGI (the Common Gateway Interface), which let a website run scripts (usually Perl back then) on the server and display the output.

From there, web technologies boomed and the ways of building websites changed dramatically. This article won't compare specific tools. Instead, it focuses on the different methods we can use to render websites, with examples in front-end Nuxt.js.

If you're new to front-end, these acronyms can be confusing at first — they were for me too. The trickiest pair is CSR and SPA, because people sometimes say "SPA" when they mean "CSR," and sometimes treat them as completely separate things. Let's clear that up.

CSR stands for Client-Side Rendering, and SPA for Single Page Application. Client-Side Rendering is the approach where the HTML is rendered in the user's browser. A Single Page Application is the type of web app that uses this approach as its core behaviour. In short, CSR is the model, and an SPA is the kind of app built on it. In an SPA, the server's initial response is often a bare-bones HTML template that JavaScript then fills with content.

Instead of serving a different HTML page per route, a client-side rendered site builds each route dynamically in the browser. This only became popular once JavaScript frameworks like React, Vue, and Angular took off.

What is a Single Page Application?

A Single Page Application (SPA) loads and updates content dynamically without refreshing the whole page. On the first load, it downloads all the HTML, CSS, and JavaScript it needs at once. After that, clicking around only swaps the content that changes, so there's no full-page reload.

The result feels smooth and app-like — closer to a native app than a traditional website.

SPA architecture

An SPA rewrites the current page with new data from the server instead of fetching a brand-new page for every interaction. A traditional multi-page site sends a complete HTML file for each page. An SPA sends the repeating shell (headers, footers, navigation) once, then fills in the right content. This makes navigation faster and more fluid, which matters a lot for things like digital commerce.

Let's make it concrete. Say you're building a web app from scratch. When you create a new Nuxt.js app, it asks you to choose a rendering mode — essentially, where your JavaScript should turn Vue components into HTML.

The question it's really asking is: "Where do you want your JS to render the HTML — in the user's browser (Single Page App) or on a web server (Universal)?"

The right answer depends on your app's needs. And because the initial load time directly affects both user experience and SEO, techniques like prerendering, caching, and progressive loading matter too.

Client-Side Rendering (CSR)

With CSR, the browser does the rendering. The server sends a minimal HTML file, and JavaScript builds the content on the client. It's the model behind most SPAs, and it gives a fast, seamless feel because only the parts that change get updated. The catch: SEO can suffer, since some crawlers struggle to index content that depends on JavaScript.

Server-Side Rendering (SSR)

With SSR, the server renders the content. It generates the full HTML and sends it to the browser, so the content is visible immediately. This is great for SEO and fast initial loads, but it adds server load and can delay the moment the page becomes interactive.

Static Site Generation (SSG)

With SSG, the content is rendered at build time. The pages are generated once into static HTML files and served as-is. Think of it like pre-cooking a meal and storing it ready to serve — pages load fast and index well. The trade-off: it suits content that changes rarely, since any update means rebuilding the static files.

How important is SEO for your web app?

Your SEO needs are the easiest way to narrow down the right rendering mode.

If SEO isn't important: Client-Side Rendering

If you don't need strong SEO, CSR is a fine choice. Frameworks like Angular and Vue made in-browser routing a smooth alternative to the old full-page-refresh approach (the classic PHP days). Imagine refreshing the whole page every time you posted a comment or hit "like" — not fun.

But what about SPA SEO? This is the main downside. Some crawlers don't execute client-side JavaScript, so they see an empty HTML page before the content has rendered. Google may also penalise pages that do heavy processing on the main thread, and performance can suffer because rendering relies on the user's device and network speed.

That said, CSR has real strengths:

• Development speed. Working entirely on the client, you don't have to worry about server compatibility — for example, browser-only APIs like the window object.
• Hosting costs. There's no rendering server to run, so you can host an SPA on any static host that serves HTML, CSS, and JavaScript.
• Performance. Because it loads a single page and simulates the rest, CSR puts less pressure on memory and processing, often giving quicker in-app navigation than SSR.

If SEO matters: SSR or SSG

SSR (Server-Side Rendering)

Unlike CSR, SSR returns a fully rendered HTML page, because the Vue code has already run on the server. The page is visible right away, even before it's interactive. Making it interactive is called hydration — the browser downloads the JavaScript and Vue takes over the page. SSR gives crawlers real content to index and proper social-media link previews, while still allowing dynamic interfaces. The caveats:

• Hosting costs. Rendering JavaScript on your own servers increases maintenance costs.
• Slower time-to-interactive. Users see content sooner, but clicks may do nothing until hydration finishes.
• UI-library compatibility. Libraries that rely on window or document can break, since the server has neither (Nuxt will throw hydration errors).

SSG (Static Site Generation)

Static Site Generation is like SSR, except pages are rendered at build time instead of on each request. Every page is generated into HTML and JavaScript, and API calls are pre-fetched and cached, so no API calls happen during client-side navigation.

This fits best when you don't need a dynamic, user-specific site — no logins, no user input, everything "read-only."

Pros:

• No server costs — you can host on a global CDN like Netlify, served quickly and consistently.
• Content is immediately available, just like SSR, with no extra API calls.
• Great for SEO, since the HTML is built before reaching the client.

Cons:

• Build time grows with the size of the app.
• Data is fetched only at build time, so you can't retrieve data dynamically based on user input.
• You may hit the same window-object compatibility issues as SSR, since window isn't available at build time.

In conclusion

None of these acronyms is a one-size-fits-all solution. Assess your site's technical needs before choosing. Here's the short version:

• SSR suits complex, interactive web apps that rely on a database or change frequently and still need SEO — at the cost of server maintenance.
• SSG suits low-cost sites whose content rarely changes and isn't user-specific, like a small presentation site or a landing page.
• CSR suits apps where SEO doesn't matter but you need a rich UI with smooth navigation and no server round-trips — and it can be hosted cheaply on a CDN or static host like Amazon S3 or Netlify.

If you're looking for a web and mobile development partner to turn your idea into a successful product, we're just an email away. Contact us at contact@wolfpack-digital.com.