Server-Side Rendering: When SSR Is Worth the Complexity and When It Is Not
SSR is not inherently better than client-side rendering. It is better for specific cases: public content, SEO, and first paint. For everything else, it adds cost without benefit.
Server-side rendering has become the default recommendation for modern web applications, often without examining whether the complexity is justified. SSR adds server computation, deployment complexity, and caching challenges. It is worth it when the benefits — SEO, first contentful paint, social sharing — matter for the specific application. It is not worth it when they do not.
When SSR is worth it
1. Public, content-heavy pages
Blog posts, product pages, marketing pages — content that needs to be indexed by search engines and shared on social media. SSR ensures crawlers and link previews see the full content immediately, without waiting for JavaScript to execute. This is the strongest case for SSR.
2. First contentful paint matters
When the browser receives complete HTML, it can display content immediately. With client-side rendering, the browser downloads JavaScript, parses it, executes it, and then renders content. For users on slow connections or devices, the difference is measured in seconds. SSR improves Core Web Vitals — specifically LCP (Largest Contentful Paint) — which affects both user experience and search rankings.
3. Social sharing and link previews
When someone shares a link on Twitter, LinkedIn, or Slack, the platform fetches the page and generates a preview. If the page is client-side rendered, the preview is empty — the fetcher does not execute JavaScript. SSR ensures the preview includes the title, description, and image.
When SSR is not worth it
1. Authenticated applications
If the page is behind authentication, search engines cannot index it and social platforms cannot preview it. SSR provides no SEO benefit and adds server computation for every request. Client-side rendering is simpler and faster for authenticated apps.
2. Rarely-changing content
If the content changes infrequently, Static Site Generation (SSG) is better than SSR. SSG generates HTML at build time and serves it from a CDN — faster than SSR, which generates HTML on every request. Use SSR only when content changes per request or per user.
3. Simple applications
If the application is small — a few pages, simple interactions — the complexity of SSR is not justified. A client-side rendered application with good performance practices (code splitting, lazy loading) will be fast enough, and the deployment is simpler.
The hydration problem
SSR sends HTML, but the page is not interactive until JavaScript hydrates it — attaches event handlers and makes it dynamic. During the gap between HTML display and hydration, the page looks ready but does not respond to clicks. This is called the 'uncanny valley' of SSR, and it is a real user experience issue. React 18's streaming SSR and selective hydration help, but the fundamental trade-off remains: the more interactivity you need, the more JavaScript you ship, and the longer hydration takes.
Choosing rendering strategy by page, not by application
The right rendering strategy is per-page, not per-application. Public pages need SSR or SSG; authenticated pages need client-side rendering. We design hybrid strategies that use the right approach for each route.
Kinematic Digital designs and implements micro-frontend architectures for enterprise organisations. See our web development and technology consulting services, or discuss your architecture.
Frequently Asked Questions
What is server-side rendering?
A rendering technique where the server generates the full HTML for a page before sending it to the browser. The browser receives a complete page that can be displayed immediately, rather than a blank page that requires JavaScript to render content.
What is the difference between SSR and SSG?
SSR generates HTML on each request. SSG (Static Site Generation) generates HTML at build time. SSG is faster but serves the same HTML to every user until the next build. SSR serves fresh content per request but requires server computation.
Does SSR improve SEO?
Yes, if your content is JavaScript-rendered. Search engines are better at indexing HTML than JavaScript-rendered content. SSR ensures crawlers see the full content immediately, without waiting for JavaScript to execute. This matters most for content-heavy sites and e-commerce.
What is hydration?
The process where client-side JavaScript attaches to server-rendered HTML, making it interactive. The server sends the HTML (fast initial display), then JavaScript hydrates the page to add event handlers and interactivity. This gives you SSR's SEO benefits and client-side interactivity.
Should we use SSR for everything?
No. SSR adds server computation cost and complexity. For content that changes rarely, SSG is better. For applications behind authentication, SSR provides no SEO benefit and adds latency. Use SSR for public, content-heavy, or frequently-updated pages where SEO and first-contentful-paint matter.