Server-side rendering creates HTML on the server for a request before the browser receives it, making meaningful content available in the initial response.
What SSR changes
SSR moves initial markup generation to the server. The browser receives HTML, then JavaScript may hydrate interactive components. SSR is not synonymous with static generation, caching, fast TTFB or successful indexation.
The proof is the response body and status for a real URL, not a framework setting.
Test the response
Inspect initial HTML with JavaScript disabled or a raw fetch. Check status, canonical, primary text and error behavior before hydration.
- Fetch initial HTML.
- Test a missing route.
- Compare rendered and raw content.
- Measure TTFB separately.
- Test cache variants.
Choose the rendering path
Use SSR where request-time data or personalisation is necessary and the origin can respond reliably. Static or cached output may fit stable public pages better.
| Question | Check | Limit |
|---|---|---|
| Initial content | Present in response HTML | HTML alone does not ensure quality |
| Error route | Correct 404/410/500 status | Client UI can mask status |
| Performance | TTFB and assets separately | One score hides layers |
SSR limits
A server-rendered page can still be slow, return an error, or hide content behind later client calls.