What Is Server-Side Rendering? HTML Built On Request
Server-side rendering (SSR) generates a page on the server for each request, sending ready-to-display HTML instead of a blank shell the browser must fill in.
A pure client-rendered app ships a near-empty HTML file and builds the page in the browser, which delays first paint and complicates SEO. SSR renders the HTML on the server first, so the user sees content immediately. It changes what your build produces and how you deploy, because there is now a running server, not just static files.
How SSR works
For each request, the server runs your app code, produces the final HTML, and sends it to the browser. The browser displays it right away, then loads JavaScript that takes over interactivity through hydration.
SSR vs client-side rendering
Client-side rendering ships JavaScript that builds the DOM in the browser, so the first response is mostly empty. SSR ships meaningful HTML on the first response. SSR improves perceived speed and SEO at the cost of running a server per request.
What you give up
- You need a running server or serverless function, not just static hosting.
- Server render time adds latency under load.
- Code must run in both server and browser environments.
Frameworks that do SSR
Next.js, Nuxt, Remix, and SvelteKit all support SSR. They blur the line between server and client, letting you write components that render in either place, with the framework wiring up hydration.
SSR in CI/CD
An SSR build produces both a client bundle and a server bundle, and the deploy target must run that server code, not just serve files. The pipeline builds both halves, then ships the server bundle to a serverless or container runtime. That makes the build artifact and deploy step heavier than a static site.
Key takeaways
- SSR renders HTML on the server per request for fast first paint and better SEO.
- It requires a running server, so the deploy is heavier than static hosting.
- CI builds both a client and a server bundle, then ships the server to a runtime.