What is Server-Side Rendering?

A bit of history

For the first decade of the web, every page was server-rendered by default — PHP, Rails, Django, ASP.NET all generated HTML on each request. Around 2014 the industry pivoted to single-page applications, where the server shipped an empty HTML shell and JavaScript built the page in the browser. That gave us slick app-like experiences but cost us SEO, social previews, and first-paint performance.

SSR is the pendulum swinging back. Frameworks like Next.js, Remix, and SvelteKit let you keep the developer ergonomics of a component-based SPA while still shipping real HTML on the first response — best of both worlds, with a few footguns.

The four-way rendering matrix

SSR is one of four rendering strategies most modern frameworks offer. Static generation builds HTML at build time and serves it from a CDN — the fastest and cheapest option for content that does not change per user. SSR builds HTML on each request — flexible, personalized, but more expensive. Incremental static regeneration combines the two, statically caching pages and refreshing them in the background. Client rendering ships an empty shell and lets JavaScript build the page — useful for highly interactive dashboards but bad for SEO.

Most real sites use all four in different places. Marketing pages are static. Personalized dashboards are SSR or client-rendered. Lists of listings that change daily use ISR.

Hydration — the part that confuses everyone

Once the server-rendered HTML arrives, the browser still needs to attach event handlers and component state to the DOM so the page becomes interactive. That step is called hydration, and it is responsible for some of the worst performance footguns in modern SSR. If you ship a megabyte of JavaScript to hydrate a marketing page, the user waits behind a busy main thread even though the HTML arrived fast. React Server Components and the App Router introduced "selective hydration" that only ships JavaScript for interactive components, which makes the whole pattern dramatically cheaper.

Why it matters

Three concrete reasons SSR matters to a founder. Search engines index what they see on the first response — if your important content depends on JavaScript that has not run yet, it does not exist as far as Google is concerned. Social link previews on Twitter, LinkedIn, and Slack are scraped without executing JavaScript — server-rendered open graph tags are the only reliable way to control how your links look when shared. And first-paint performance — the metric users actually feel — is dramatically better when the HTML arrives ready to render.

At QUANT LAB

Every public-facing page we ship is server-rendered by default. The site you are reading is Next.js running on the App Router with React Server Components — the modern evolution of SSR where most components run on the server and ship zero JavaScript to the client. Our web application work and SaaS platforms use the same approach.

Edge vs origin rendering

Modern hosting platforms let you choose where the server rendering happens. Origin rendering runs in a single region — typically a Node.js or Bun process colocated with your database — which keeps data access fast but adds round-trip latency for distant users. Edge rendering runs at hundreds of points of presence worldwide on the CDN's edge runtime, which is fast for users everywhere but cannot use raw database connections and is constrained to smaller runtime APIs. The decision is per-route, not per-app, and the right answer usually mixes both.