sdlc.dev

Frontend engineer path · The network and the user · Topic 13 of 17

Rendering strategies: CSR, SSR, static and streaming

Not started

Every page's HTML gets made somewhere: in the browser from JavaScript, on a server for each request, or once at build time. Most frameworks now let you choose per route, and mix them within a page. The choice is a trade between how soon content appears, how fresh and personal it can be, how much it costs to serve, and how much JavaScript the visitor must run before the page responds.

Why it matters: Choosing where HTML is produced decides your first paint, your server bill, how fresh pages are and how much JavaScript every visitor downloads.

  1. 1Client-side rendering

    The server sends an almost empty page and a bundle; the browser builds the HTML. Simple to host, slow to first content on weak phones.

  2. 2Server-side rendering

    The server builds the HTML for each request, so content arrives in the first response. The page still needs JavaScript to become interactive.

  3. 3Static generation

    The HTML is built once, ahead of time, and served from a CDN. The fastest and cheapest, as long as the content can be the same for everyone.

  4. 4Streaming and hydration

    Streaming sends the HTML in pieces as each part is ready. Hydration attaches event handlers to server-rendered HTML; the less of it, the sooner the page responds.

1

How it works

The explanation, with examples you can run.

The options

Client-side rendering (CSR). The server returns a shell and a script bundle; the script fetches data and builds the DOM. Hosting is trivial and navigation inside the app can be quick, but nothing useful appears until the bundle has downloaded and run, which hurts LCP on slow phones and networks. Good for tools behind a login where search engines don't matter.

Server-side rendering (SSR). The server runs the same components for each request and sends real HTML. Content appears in the first response and can be personalised, but every request costs server time, and the time to first byte includes your slowest data fetch unless you stream.

Static generation (SSG, prerendering). Pages are rendered at build time and served as files, ideally from a CDN. It is the fastest and cheapest to serve, but the content is the same for every visitor and only as fresh as the last build. Many frameworks add regeneration: rebuild a page in the background after a time limit or when content changes, which brings static pages close to SSR's freshness.

Streaming. The server sends the document in chunks: the head and page shell first, then each section as its data arrives. The browser starts parsing, fetching CSS and painting from the first chunk. A slow recommendations panel no longer delays the whole page.

Hydration

Server-rendered or static HTML is visible but not yet interactive. Hydration runs the components again in the browser so they can attach event handlers and take over. Until it finishes, clicks may do nothing, and the work itself is a long task that can hurt INP. Ways to do less of it:

  • Partial or island hydration: only the interactive parts (a cart button, a search box) ship and run JavaScript; the rest stays plain HTML.
  • Server components: some frameworks render parts only on the server and send no JavaScript for them at all.
  • Progressive enhancement: make forms and links work as plain HTML, so the page is usable before any script runs.

Choosing

  • Same for everyone, changes rarely: static, served from a CDN, with regeneration on change.
  • Personal or changes every request, and first paint matters: SSR, streamed.
  • An app behind a login with heavy interaction: CSR is acceptable, but keep the shell fast.
  • Most real sites mix them: a static marketing page, a server-rendered product page, a client-rendered dashboard.

Whatever you choose, cache what you can (static output and shared SSR responses at a CDN), and measure the result with field data rather than assuming one strategy is fast.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.A documentation site changes a few times a day and looks the same for every visitor. Which strategy fits best?
  2. 2.A server-rendered product page shows its content quickly, but taps do nothing for two seconds. What is the likely cause?
  3. 3.What does streaming the server response buy you?

0 of 3 right so far. Get all three to finish this topic.

Go deeper