What Is Server-Side Rendering?

How Server-Side Rendering Works

Server-side rendering is defined by the Chrome team as “rendering an app on the server to send HTML, rather than JavaScript, to the client.” When a request arrives, the server runs the application, produces the fully-formed HTML for that URL, and returns it. The browser can paint meaningful content as soon as the response arrives, before any application JavaScript has downloaded or executed. The page is a finished document, not a set of instructions for building one.

This is the older model of the web — every classic server framework worked this way — and it has come back into favor precisely because it sidesteps the costs of doing everything in the browser. Its performance profile is the mirror image of client-side rendering: First Contentful Paint is fast because usable content is in the first response, while time to first byte is slower and server compute higher, because the server does rendering work on every request. The “Rendering on the Web” guidance frames SSR’s headline tradeoff bluntly as higher server cost in exchange for a complete experience delivered sooner.

For search, that completeness is the whole point. The content a crawler needs is present in the server response, so there is no dependence on Googlebot rendering JavaScript in a deferred queue and no risk of indexing an empty shell. This is why, when Google retired dynamic rendering as a recommendation, it pointed teams toward server-side rendering, static rendering, and hydration as the durable answers.

SSR, Static Rendering, and Hydration

Server-side rendering rarely ships alone. It sits in a family of related techniques:

• Static rendering produces HTML at build time rather than per request, generating a file for each URL ahead of time. It captures SSR’s crawler-friendliness with none of the per-request server cost, at the price of needing a rebuild when content changes.
• Hydration is the bridge to interactivity: the server sends rendered HTML, then client-side JavaScript “hydrates” it by attaching state and event handlers to the existing DOM instead of rebuilding it. Done well, the user gets instant content and eventual interactivity.
• Rehydration extends this to keep the DOM updated with the latest state after that first pass — powerful, but the most common source of the “SSR page fine, hydrated page broken” mismatch.

Example of Server-Side Rendering

The authoritative documented treatment of SSR is again “Rendering on the Web” by Google engineers Addy Osmani and Jason Miller (first published February 2019, maintained since). The article maps the full rendering spectrum and places SSR as the option that “delivers a complete experience to crawlers,” contrasting it directly with client-side rendering that “works but needs testing.” Its documented tradeoff table is specific: SSR wins on First Contentful Paint and crawler completeness, loses on time to first byte and server cost. These aren’t invented benchmark figures — they are the directional tradeoffs the Chrome team publishes as guidance for choosing an architecture.

The reason this example generalizes is that Google’s own Search documentation reaches the same conclusion from the opposite direction. When it deprecated dynamic rendering, it wrote that the technique “was a workaround and not a recommended solution” and steered developers to “server-side rendering, static rendering, or hydration” instead. Two independent Google sources — one about web performance, one about crawling and indexing — converge on the same recommendation: put the content in the HTML the server sends. That convergence, not any single case study, is the strongest evidence for why SSR remains the default recommendation for content that has to be found.

Frequently Asked Questions

The Bottom Line

Server-side rendering does the assembly work up front, on the server, so the browser and the crawler both receive a page that is already whole. It trades cheaper servers and instant client navigation for a heavier per-request cost, and in return it makes content unconditionally visible to search engines. The discipline that keeps it valuable is restraint on the client side: the HTML you send must stand on its own, and hydration must enhance it rather than quietly rewrite what a crawler saw.