The oldest performance trick is still the most reliable: serve HTML that already contains the answer. Server-side rendering does the rendering work before the user ever waits on it.
The client-side framework era taught a hard lesson. When the browser has to download, parse, execute and hydrate before showing content, the boot cost lands directly on the user.
SSR and its modern variants move that cost to the server. The user receives finished HTML, paints immediately, and the interaction cost stays a server problem instead of a main thread one.
What SSR Buys
SSR buys first paint. The HTML arrives rendered, so LCP content paints without waiting on JavaScript execution, which removes the biggest client-side boot cost.
It buys crawler readability. The full content sits in the initial markup, which serves the technical SEO pass and the answer layer without rendering JavaScript.
It buys predictability. The server renders the same markup every time, so the page behaves identically across devices that fail or vary in the client-side rendering run.
The Cache Is the Second Half
Rendering on every request strips SSR of its gain. The finishing move is caching the rendered HTML, so the expensive render runs once and the edge or CDN serves the repeats.
Cache by content type. Anonymous pages cache hard, personalized pages cache with a key that includes the variation, and session-bound views bypass to the real-time render.
The revocation story sets the ceiling. Precise purge by content tag lets the cache be aggressive, and the architecture review covers how fast a stale page can disappear.
| Page Type | Cache Strategy | Bypass When |
|---|---|---|
| Anonymous content | Cache hard | Content changes |
| Personalized | Key by variation | Session context |
| Post-login | Session cache | User state changes |
| Transactional | No cache | Always real time |
Streaming and Partial Hydration
Streaming ships the rendered shell first and the slow regions behind it, so the user interacts with the visible page while the heavy parts finish.
Partial hydration keeps the interactive islands small. Only the components that need JavaScript hydrate, which cuts the hydration bill to the fraction that actually runs.
The combination lands most pages at near-static speed with a fraction of the weight, and it is why modern SSR beats the all-or-nothing choice.
SSR Failures
Full-page hydration is the classic failure. A server-rendered page that re-runs the whole framework client-side doubles the work instead of halving it.
No cache is the economic failure. Rendering on every request trades the user bottleneck for a server bottleneck, and the busy-site crash follows.
Mixed rendering is the creeping failure. Some templates SSR, some client-render, and the field score reflects whichever type each page happens to use.
- Rendering server-side then hydrating the whole tree
- Rendering every request with no cache
- Inconsistent rendering modes across templates
- No streaming for the pages that need it
The Render Cache Ladder
Build the ladder: browser cache, edge cache, rendered HTML, then templates. Each rung intercepts a share of the requests so the server and the network both win.
Stream the shell, hydrate the islands. The visible page appears fast and the interactions that need code get it exactly where they must run.
Measure the split. Field LCP and time-to-first-paint per template, plus origin render latency, show whether the trade is landing where designed.
Real-World Considerations
Server capacity is the new budget line. Un-cached SSR multiplies origin load, and the capacity plan has to price the render cost, not just the bytes.
Hosting differences matter. Edge platforms make the render-cache ladder turnkey; a legacy server needs the same layers built by hand.
The rendering architecture interacts with the edge functions guide. Cached HTML plus an edge function that personalizes a slot covers most personalization without breaking the cache.
Where SSR Wins
Content-heavy and crawler-dependent sites win first, because the rendered HTML serves the reader and the answer layer at once.
App-like product surfaces win too, when the interaction islands are genuinely small and the shell actually benefits from server render.
Session-heavy transactional flows gain the least; the real-time render bypasses the cache and the SSR value stays marginal.
Implementation Checklist
- Render the shell server-side
- Stream the slow regions behind the shell
- Hydrate only the interactive islands
- Cache rendered HTML by content type
- Set precise purge by content tag
- Measure field LCP and origin render per template
Final Thoughts
SSR answers the boot question by moving work to your server and your cache. The rendered shell, the streaming regions and the interactive islands each buy a slice of first paint.
Design the render cache ladder and hydrate sparingly. The user gets fast paint, the crawler gets the content, and the edge gets the repeat traffic.
Frequently Asked Questions
For first paint and crawlers, yes, if the cache exists and hydration is partial. Without those two, the benefit collapses toward the cost.
No. Interactive components still need code, but partial hydration bounds it to the islands that actually run it.
When every request re-renders at the origin and the hydration re-runs wholesale client-side. Both are design failures, not SSR failures.
