---
type: Glossary Term
title: "Server-Side Rendering (SSR)"
description: "Generating HTML on the server for every request, then sending it to the browser."
resource: "https://prerendering.com/glossary/ssr"
tags: [rendering, glossary]
timestamp: 2026-05-11T00:00:00Z
---

# Server-Side Rendering (SSR)

Generating HTML on the server for every request, then sending it to the browser.

In SSR, the framework runs on each incoming request, fetches data, generates HTML, and sends it back. Crawler-visible HTML is generated fresh per request. TTFB depends on origin response time, typically 200ms to 1.5s. Examples: Remix everywhere, Next.js with force-dynamic, Express + EJS, classic PHP/Rails apps.

Also known as: SSR.

## When it matters

- Personalized or auth-gated content that changes per user and cannot be safely cached.
- Pages that depend on data with sub-minute freshness (live pricing, inventory, dashboards).
- Smaller sites where cold-cache TTFB of 200-800 ms is acceptable and rebuild cycles for SSG are too slow.
- Pages where the URL contains the full personalization state (`?user=...`) and a CDN edge cache would be ineffective anyway.

## Common pitfalls

- Origin overload during crawl spikes — SSR scales linearly with traffic, unlike SSG/CDN delivery.
- Hidden client-side hydration that adds the real content after server HTML (effective CSR, not SSR).
- Mixing `force-dynamic` and `force-static` in the same template, producing inconsistent crawler experiences.
- Believing SSR alone solves JS SEO — without disciplined Server Components, much of the work still happens in the browser.

## How to verify

- curl -I https://your-site.com/route — confirm `cache-control` is appropriate; 100% miss rate at the CDN is an SSR red flag for static-eligible templates.
- Crawler analytics — average response time for Googlebot on SSR routes should stay below 800 ms; sustained slowdown reduces crawl rate.
- Next.js: build output shows `ƒ (Dynamic)` for SSR routes vs `○ (Static)` for SSG — verify intent matches reality.
- Compare server-rendered HTML to client-rendered DOM with browser disabled JS — text and links must match.

## External references

- [web.dev: Rendering on the web](https://web.dev/articles/rendering-on-the-web)
- [Next.js: Server and Client Components](https://nextjs.org/docs/app/getting-started/server-and-client-components)

## Related

- [Prerendering vs SSR vs SSG: 2026 Decision Guide](/blog/prerendering-vs-ssr-vs-ssg-decision-guide.md)