10% off every plan until October — because my rent's due.
BasicBS.
Back to blog

SSR vs CSR: 5 Page Types Developers Should Render Server Side

Decorative SSR versus CSR title card

Server-side rendering (SSR) builds the HTML on the server before it reaches the browser; client-side rendering (CSR) ships a near-empty page and lets JavaScript build the interface once it arrives. The quick rule: lean on SSR or prerendering when a page needs fast initial content or needs to be crawled, and lean on CSR for app-like screens where interactivity matters more than first paint. Most real projects end up mixing both.

TL;DR:

  • Server-side rendering provides faster initial content and better SEO for pages with static or semi-static data, especially when caching is effectively implemented.
  • Client-side rendering increases load on the browser and may cause delays in first paint, particularly on slow devices or networks, but reduces server load after the initial page.
  • Prerendering at build time suits content that does not change often, like marketing pages and blogs, avoiding repeated server computations.
  • Hybrid solutions like React Server Components enable streaming static content while interactive elements load separately, balancing performance and interactivity.
  • Testing and measuring real user metrics on actual devices and networks are essential before implementing or changing rendering strategies to ensure they deliver tangible benefits.
BasicBS
Build A Faster, Search-Friendly Website
BasicBS builds high-performing websites with managed hosting, SSL, SEO support and monthly updates for a straightforward online presence.
Explore BasicBS websites

Table of Contents

SSR, CSR and prerendering: what each one actually does

The core difference comes down to where the HTML gets made. With SSR, the server generates the markup on request, or pulls it from a cache, and the browser can show something before any JavaScript has run, which is the same decisive split that MDN’s SSR glossary entry describes: server versus browser produces the initial HTML. With CSR, the browser downloads a slim HTML shell and a JavaScript bundle, then parses and executes that bundle to build the DOM from scratch, a process that includes hydration once the JavaScript takes over any server-rendered markup.

  • SSR: HTML generated per request or served from cache, with streaming options that affect how quickly bytes reach the browser.
  • CSR: a minimal shell loads first, then JavaScript builds the page, so the first paint waits on download, parse and execution.
  • Prerendering (SSG): HTML gets built once at deploy time, which suits content that does not change per user or per request.

The time and compute cost sits in different places for each. SSR spends it on the server for every request (unless cached); CSR spends it in the visitor’s browser; prerendering spends it once, before anyone visits at all.

Performance, SEO and the maintenance cost of each approach

Neither approach wins Core Web Vitals outright. According to Web, the result depends on JavaScript size, data fetching patterns, server latency, caching and the device or network the page loads on. SSR tends to help Time to First Byte perception and First Contentful Paint because there’s real markup to show straight away, but it adds rendering work on the server. CSR can lighten server load after the initial load, but on a slow phone over patchy 4G, that blank screen while JavaScript loads can drag on.

  • FCP and LCP: generally favour SSR or prerendering, since there’s HTML to paint immediately rather than waiting on a JavaScript round trip.
  • TTFB: can be worse for SSR under load unless you’re caching, because the server does fresh work per request.
  • TBT and INP: often favour SSR with smaller client bundles, since there’s less JavaScript fighting for the main thread.

A page that ships less JavaScript and server-renders its first view tends to respond faster to input, because the main thread isn’t tied up building the DOM from scratch, a pattern web.dev’s rendering guide attributes to streamed HTML letting the browser parse and paint in chunks rather than in one long blocking task.

SEO is where CSR carries the most risk. A CSR page isn’t automatically invisible to search engines, but it’s an avoidable gamble, and checking your rendered output with URL inspection tools or a browser with JavaScript disabled tells you fast whether content is actually there for a crawler. Operationally, SSR means managing server compute and caching layers; CSR means managing bundle size and code-splitting. Progressive enhancement, where core content and navigation work without JavaScript, tends to sit more naturally with server rendering.

SSR and CSR rendering paths compared

Picking SSR, CSR, SSG or prerendering by page type

Different pages on the same site often want different answers, and that’s fine, this isn’t a one-size-fits-all decision.

  1. Marketing pages and landing pages: prerender or statically generate these. Content rarely changes per visitor, so build-time HTML is the cheapest and fastest option.
  2. Blog posts and content pages: SSG works well for most, but switch to SSR if content updates frequently and you can’t afford a rebuild each time.
  3. Dashboards and logged-in apps: CSR, or client components, usually fit best, because the data is personal, changes constantly, and SEO doesn’t apply.
  4. Hybrid pages: a product page might server-render the description and price for crawlers, then hand a “add to basket” widget to the client for interactivity.
  5. High-traffic pages with unpredictable load: weigh request-time SSR against caching costs; if the content doesn’t change per user, cached SSR or prerendering avoids paying server compute on every visit.

A per-route checklist for deciding how to render

Run each route through the same short list of questions rather than picking one architecture for the whole site.

  • Does this page need meaningful HTML for first paint or for a search crawler to understand it?
  • Is the content the same across users, or personalised in a way that makes caching pointless?
  • Does initial interaction responsiveness matter more here than keeping the JavaScript bundle small?
  • Could prerendering or a server snapshot cover any SEO risk without a full SSR setup?
  • Have you tested the rendered output, not just the source code, to confirm what a crawler or a slow device actually sees?

Pro Tip: Check your page with JavaScript disabled in devtools before you assume it’s crawlable: if the content disappears, so does your SEO case for CSR.

How to measure the real impact before you change anything

Guesswork is how teams end up rewriting a perfectly fine site for no measurable gain, so test first.

  1. Collect FCP, LCP, TTFB, TBT or INP, total JavaScript transfer size and main-thread time for a handful of representative pages.
  2. Run Lighthouse and PageSpeed Insights for lab data, then WebPageTest for filmstrip views and network waterfall detail.
  3. Throttle to a mid-range device and a 4G connection, since your dev machine on fibre tells you almost nothing useful.
  4. Roll changes out to a slice of traffic where possible and compare real-user metrics against the baseline before committing.

MDN’s performance best practices guide recommends exactly this combination: profile on real devices and networks, using browser devtools alongside Lighthouse, PageSpeed Insights and WebPageTest, rather than trusting a single score. Measuring JavaScript transfer size and main-thread time alongside the usual paint metrics tends to reveal problems a single Lighthouse score hides.

Server components, streaming and mixing the two approaches

Modern frameworks blur the line on purpose. React Server Components, as implemented in Next.js, let you render and cache UI on the server while streaming parts of the page to the browser as they become ready, which helps FCP without forcing an all-or-nothing choice.

  • Server components suit static or data-heavy UI: product listings, article bodies, navigation.
  • Client components suit anything stateful or interactive: forms, filters, modals, anything reacting to a click.
  • Rehydration still costs something wherever client components sit, and caching strategy needs thought per route, not per site.

What we’ve learned building small-business sites

For most SMEs and event sites, server-rendered pages with a bit of client-side interactivity sprinkled on top beat a fully custom hybrid setup. Cutting the rubbish and keeping the stack simple gets a fast, crawlable site live without the engineering overhead most small businesses never needed in the first place.

— Rhys

How BasicBS builds fast, SEO-friendly sites without the faff

If all this has convinced you that your site needs a rethink, you might consider a pragmatic setup with server-rendered pages for speed and SEO, adding interactivity only when necessary, available as pay monthly website design without upfront costs or long contracts.

BasicBS

Our website design includes managed UK hosting, SEO support and AI search training, delivered within a typical timeframe. Whether you’re after a simple website for a sole trader or a full build for a growing team, our services page lays out what’s included, and transparent pricing means you’ll know the Website Sale! plan costs £10 a month before you commit to anything. Get in touch for a quote and guidance on typical delivery times.

Where these claims come from

Sources

FAQ

How can you tell if a website is SSR or CSR?

View the page source in your browser: if the full content appears in the raw HTML before any JavaScript runs, it’s server-rendered or prerendered. If the source shows little more than an empty shell and a script tag, the content is being built client-side.

When should you use React with SSR versus CSR?

Use SSR in React, typically via Next.js, for pages that need fast first paint or need to be indexed, such as marketing pages or product listings. Use CSR for logged-in, highly interactive views like dashboards, where content is personalised and SEO doesn’t apply.

When should you choose SSR over other options?

Choose SSR when a page needs fresh, request-specific HTML that can’t be prerendered at build time, but still needs to load fast and be crawlable. Google’s own guidance favours SSR or prerendering over client-side-only rendering for single-page app content that needs to be found in search.

Is Angular considered CSR or SSR?

Angular is built as a client-side framework by default, rendering the app in the browser, but it supports server-side rendering through Angular Universal for teams that need faster first paint or better crawlability. Which mode you use depends on the project’s setup rather than any fixed rule.

Back to blog