Server-side rendering (SSR) means the server generates the HTML of a page when a request arrives and sends the finished markup to the browser. web.dev defines it as “rendering an app on the server to send HTML, rather than JavaScript, to the client.”
How does SSR work?
- The browser requests a URL.
- The server fetches the needed data from a database or API.
- It combines a template with that data and returns HTML.
- The browser shows the page right away.
- In many frameworks, JavaScript then loads and makes the page interactive. web.dev calls this step hydration.
MDN notes that SSR and client-side rendering (CSR) can be combined in one application. It also separates SSR, where HTML is created at request time, from static site generation, where it is created at build time.
SSR compared with CSR and SSG
web.dev lists the effects. SSR gives a faster first contentful paint and less JavaScript work for the browser. Because the server computes every response, time to first byte is longer than for pre-built static files. A page can also look finished before scripts have run, so clicks do nothing for a moment. EPAM adds that SSR needs more server capacity than client-side approaches.
What does SSR mean for SEO?
The initial HTML already contains the content, so crawlers do not have to run JavaScript to see text and links. Google writes that server-side or pre-rendering “is still a great idea” because it makes a site faster for users and crawlers, and not all bots can run JavaScript. Google calls dynamic rendering (serving crawlers a separate pre-rendered version) a workaround and not a long-term solution, and names server-side rendering, static rendering or hydration as alternatives. The Next.js documentation also calls its SSR “Dynamic Rendering”, which is not the same as the dynamic rendering workaround Google describes.
| Approach | Where and when is the HTML built? | Content in the delivered HTML? | Google's position |
|---|---|---|---|
| Client-side rendering (CSR) | in the browser with JavaScript; data fetching, templating and routing run on the client | no, only after JavaScript has run | Google renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript |
| Server-side rendering (SSR) (this term) | on the server, for each request | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Static site generation (SSG, static rendering) | at build time; usually one HTML file per URL ahead of time | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Incremental static regeneration (ISR) | prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js) | yes, from the cache; the older version is served until regeneration finishes | no specific statement from Google |
| Prerendering | at build time; the client-side app is run and its initial state saved as static HTML | yes (initial state) | Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers |
| Dynamic rendering | a rendering server builds HTML only for detected crawlers; users get the client-side rendered version | only in the version served to crawlers | Google calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content |
Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .
Example
<!-- Response from an SSR server -->
<h1>Running shoes</h1>
<p>Our range for road and trail ...</p>
<script src="/client.js"></script>
With client-side rendering, the same response would only contain an empty <div id="app"></div>.
Common mistakes
- Overlooking the wait for the first byte: If the server renders every page per request, web.dev says time to first byte can increase.
- Ignoring the hydration gap: The page looks ready but does not respond until the component scripts have run and the event handlers are attached.
- Shipping the data twice: With SSR plus rehydration the server sends the rendered UI, the source data and a complete copy of the UI implementation. web.dev lists this as a drawback.
- Equating it with dynamic rendering: Dynamic rendering serves a separate version only to detected crawlers. SSR sends the same response to everyone.
FAQ
What is SSR vs CSR? With SSR the server delivers HTML, with CSR the browser builds it from JavaScript.
Is React CSR or SSR? Both are possible. React can render in the browser or, with a framework such as Next.js, on the server.
Sources
- Server-side rendering (SSR) – MDN Glossarydeveloper.mozilla.org
- Rendering on the Web – web.devweb.dev
- Dynamic rendering as a workaround – Google Search Centraldevelopers.google.com
- JavaScript SEO basics – Google Search Centraldevelopers.google.com
- Server-side rendering – Next.js Docs (Pages Router)nextjs.org
Last updated: