// web · rendering

How rendering works: server-side vs client-side

2026-08-16 · 3 min read

Same page, two strategies: the server builds the HTML before sending it, or the browser builds it from JSON after arriving. This guide races the two approaches side by side, shows exactly what travels the wire in each, and ends with the honest trade-offs — simulators included.

mindmap — quick refresh rendering — who builds the HTML? the question the browser can only paint HTML someone must turn data into it server-side (SSR) server: template + data → full HTML first response already readable view-source shows your content works without JS; crawlers see everything client-side (CSR) server sends a shell + a JS bundle JS fetches JSON, builds the DOM in the browser blank until the bundle runs rich app-like interactivity after trade-offs SSR: faster first paint, more server work CSR: fast shell, slow first content, great in-app feel hybrids exist: SSR first paint + JS hydration

Prerequisites: How browsers work (the rendering pipeline) and How HTTP servers work (static vs dynamic responses).

A browser can only paint what its rendering pipeline is given: HTML. But your actual content — students, products, scores — lives in a database as data. Somewhere between the database and the screen, someone has to turn data into HTML. The entire server-side vs client-side rendering debate is one question:

Who builds the HTML — the server before sending, or the browser after arriving?

The race: same page, two strategies

Watch both approaches deliver the same student list, side by side:

The shape of the result is worth memorizing. SSR does its work before the first byte leaves: slower to start responding, but what arrives is immediately paintable. CSR responds instantly with a nearly-empty shell — great first byte! — then makes the user wait through a JS download, its execution, and a second round trip for data before anything real appears. On fast Wi-Fi you barely notice; on a phone on 4G, the CSR gap is very visible.

What actually travels the wire

The race explains when; this explains what. Step through the actual responses each strategy sends:

That difference — content in the HTML vs content arriving separately as JSON — has consequences beyond speed:

  • View-source is the SSR litmus test. If your data is in the page source, the server rendered it. (Your lab this week proves it — see below.)
  • Robots and previews read HTML. Search crawlers and link-preview bots get the SSR page's content for free; a CSR page shows them an empty <div> unless extra machinery steps in.
  • No JavaScript, no CSR. SSR pages degrade gracefully; a CSR page without its bundle is a blank rectangle.

So which one? (The honest trade-offs)

Neither wins outright — they optimize different moments:

aspectserver-side (SSR)client-side (CSR)
First meaningful paintFast — the HTML arrives ready to paintSlow — bundle download, then a JSON fetch, first
Navigating after loadFull page reload on every clickInstant, app-like updates
Server cost per viewRenders every page view (CPU per request)Serves static files + JSON (cheap)
SEO & link previewsContent visible to crawlers for freeNeeds extra machinery (prerendering)
With JavaScript offFully readableBlank page

The rule of thumb: content sites lean SSR (blogs, docs, shops — first paint and SEO dominate), tools lean CSR (dashboards, editors — you load once, then interact for an hour). And the modern mainstream is deliberately both: frameworks like Next.js render the first view on the server, then hydrate — attach JavaScript so subsequent interaction behaves like CSR. Once you understand the two pure strategies, hybrids are just mixing the timelines you watched above.

Now prove it with your own hands: Server-side rendering in pure Python builds the SSR half in ~45 lines of standard library, no framework.

Takeaways

  • Rendering = turning data into HTML. The only question is where it happens.
  • SSR: server sends finished HTML → fast first paint, view-source shows content, works without JS, costs server CPU per view.
  • CSR: server sends a shell + bundle; the browser fetches JSON and builds the DOM → slow first content, excellent app-like feel afterwards.
  • Check view-source when you meet a new site — it tells you the rendering strategy in five seconds.
  • Modern frameworks hybridize (SSR first paint + hydration); you now have the vocabulary to read their docs.

References

  • MDN Web Docs. (n.d.). Introduction to the server side. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction
  • Osmani, A., Miller, J., & Grigorik, I. (2019). Rendering on the web. web.dev. Retrieved August 16, 2026, from https://web.dev/articles/rendering-on-the-web
  • Vercel. (n.d.). Rendering: server-side rendering (SSR) (Next.js documentation). Retrieved August 16, 2026, from https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering