SSR vs CSR — Server-Side vs Client-Side Rendering

What is SSR?

In server-side rendering, the web server receives a request, fetches any required data (from a database, CMS, or API), renders the full HTML document, and sends it to the browser. The browser displays the content immediately — no JavaScript execution required to see the page.

The trade-off is that every request generates server work. A Node.js process (or equivalent) must render the template before the first byte can leave the server, which increases TTFB compared to serving a cached static file. In practice, SSR responses are often cached at the CDN edge with a short TTL to mitigate this.

Once the HTML is in the browser, the page may still need to download a JavaScript bundle so that interactive elements (forms, dropdowns, client-side navigation) work. This "attaching" phase is called hydration. If the JS bundle is large or slow to parse, there can be a visible delay between seeing the page and being able to interact with it — an issue tracked by the Interaction to Next Paint (INP) Core Web Vital.

// Next.js SSR example — runs on the server for every request
export async function getServerSideProps(context) {
  const { params } = context;
  const product = await db.products.findById(params.id);

  return {
    props: { product }, // sent as props to the React component
  };
}

What is CSR?

In client-side rendering, the server sends a minimal HTML document — essentially a <div id="root"></div> and a <script> tag pointing to the application bundle. The browser downloads the bundle, executes it, and React (or Vue, Angular, etc.) builds the entire DOM in the browser.

The initial TTFB is low because the server returns a tiny file instantly. However, FCP is higher because nothing meaningful appears on screen until the JS bundle has been downloaded, parsed, and executed. On slow mobile connections or low-end devices, this creates a frustrating blank-page experience.

Once the application is loaded, subsequent navigation is extremely fast — the JS router swaps components without a round-trip to the server. This is why CSR became the dominant pattern for dashboards and tool-like applications where users spend long sessions after the initial load.

Bundle size is the most important performance lever for CSR. A 1 MB uncompressed bundle on a 3G connection adds several seconds before content appears. Code-splitting by route (loading only the JS for the current page) is the standard mitigation.

// CSR — data fetched in the browser after component mounts
function ProductPage({ id }) {
  const [product, setProduct] = React.useState(null);

  React.useEffect(() => {
    fetch(`/api/products/${id}`)
      .then(r => r.json())
      .then(setProduct);
  }, [id]);

  if (!product) return <Spinner />;
  return <ProductDetail product={product} />;
}

Static Site Generation — the third path

SSG pre-renders every page to a static HTML file at build time. The files are deployed to a CDN; no server computation happens per request. TTFB is minimal, FCP is the fastest achievable, and there is no server to scale or crash.

The limitation is freshness — content is only as up-to-date as the last build. For blogs, documentation, or marketing pages that update a few times a day, this is fine. For a live stock ticker, it is not.

Next.js introduced Incremental Static Regeneration (ISR) to address this: pages are statically generated but automatically regenerated in the background on a configurable interval, combining SSG performance with SSR freshness.

Choosing between SSG, SSR, and CSR is similar in some ways to choosing between microservices and a monolith — the "right" answer depends on your traffic patterns, team size, and content update frequency, not on which technology sounds more modern.

Perceived performance and the role of hydration

A page can look fast but feel slow. SSR delivers visible content quickly (good FCP), but if the hydration bundle is large, the page may appear interactive whilst actually ignoring clicks — a phenomenon sometimes called the hydration gap.

Modern frameworks address this with selective hydration strategies:

• Islands architecture (Astro, Fresh) — only explicitly interactive components ship JavaScript; the rest is static HTML.
• React Server Components — server-only components produce UI with zero client JS; only "use client" components hydrate.
• Streaming SSR — HTML is streamed to the browser progressively; the browser can render and hydrate parts of the page before the full response arrives (Next.js App Router, React 18's Suspense).

Understanding these trade-offs is essential vocabulary for frontend architecture discussions, similar to how REST vs GraphQL debates centre on data-fetching efficiency.

How engineers talk about SSR vs CSR

Decision guide

• SEO-critical page (blog, product listing, marketing) → SSG or SSR
• Content is the same for all users and changes infrequently → SSG
• Content is personalised per user but SEO still matters → SSR
• Content updates very frequently (live data) with SEO needs → SSR with short CDN TTL or ISR
• Authenticated dashboard, admin tool, no SEO requirement → CSR is fine
• Social sharing previews (og:image, og:title) must work → SSR or SSG
• Maximum performance, scale to zero server cost → SSG + CDN
• Complex app — different pages have different needs → Mix strategies per page (Next.js, SvelteKit)