SSR vs CSR · Rendering Strategies for SEO and Performance

Pure client-side rendering sends a nearly empty HTML shell to the browser. All meaningful content — text, headings, meta tags, links — is generated by JavaScript running in the browser after the initial HTML loads. For regular users with fast devices and connections this is often acceptable. For search engine crawlers and for Core Web Vitals, it creates significant problems.

SEO problems specific to CSR

• Two-wave indexing delay. Content only exists after JavaScript executes — this is always Wave 2 for Googlebot, meaning days or weeks of indexing delay (see JavaScript SEO guide).
• Empty pages on crawl failure. If JavaScript fails to execute (network error, browser incompatibility, resource blocked), Googlebot may index a blank or near-empty page.
• Soft 404s. CSR applications that render "page not found" states via JavaScript while returning a 200 HTTP status are indexed as normal pages.

Core Web Vitals problems specific to CSR

• LCP is always delayed. The LCP element cannot paint until the JavaScript bundle downloads, parses, executes, and renders the DOM. This is inherently slower than receiving the element in HTML.
• High INP risk. Large JavaScript bundles create long tasks during initial execution, blocking interaction for seconds after the page visually loads.
• FCP (First Contentful Paint) is delayed. The browser shows a white screen until the JavaScript renders the first content — users see nothing meaningful during the entire JS execution period.

Server-side rendering generates the full HTML page on the server for every request and sends it directly to the browser. The browser receives complete, indexable, renderable HTML immediately — no JavaScript required to see the content. JavaScript is then loaded to "hydrate" the HTML and add interactivity.

SEO benefits of SSR

• Content is in the HTML that Googlebot receives in Wave 1 — no rendering queue delay
• All meta tags, canonical, hreflang, and structured data are present in the initial HTML
• Correct HTTP status codes are served server-side (404, 301, 200)
• All URLs are accessible as distinct HTML documents with their own content

CWV benefits of SSR

• LCP can begin as soon as TTFB completes — the LCP element is in the HTML, no JS wait
• FCP is faster — browser can begin painting immediately from the HTML response
• Overall Lighthouse/PageSpeed scores significantly higher than equivalent CSR

Trade-offs

• Higher server cost. Every page request generates HTML on the server, requiring more CPU than serving a static file or cached response.
• Higher TTFB than static files. Server processing time is always greater than zero — SSR pages have higher TTFB than CDN-cached static HTML (though caching SSR output at the CDN mitigates this).
• Hydration complexity. Ensuring the server-rendered HTML matches what the client-side JavaScript would have rendered (hydration mismatch) is a common source of bugs in SSR applications.

Static site generation builds all pages at deploy time — generating complete HTML files from your content and storing them as static files. These files are served directly from a CDN with zero server processing, giving TTFB values under 50ms and perfect scalability.

SSG is the optimal choice for content that does not change frequently and does not require per-request personalisation. SEO performance is excellent — complete HTML served instantly from CDN edge, no JavaScript dependency for content. CWV scores are typically highest of all rendering strategies because TTFB is minimal and there is no render-blocking JavaScript.

SSG limitations: build time grows with the number of pages (a 100,000-page e-commerce site can take 30+ minutes to build); content updates require a rebuild and redeploy cycle; real-time or personalised content cannot be statically generated.

Incremental Static Regeneration (ISR), introduced by Next.js and now available in other frameworks, generates pages on first request like SSR, then caches and serves the generated HTML as a static file — like SSG. After a configurable revalidation period, the next request triggers a background rebuild of that specific page, updating the cached static HTML without requiring a full site rebuild.

ISR provides the performance characteristics of SSG (CDN-cached static HTML, minimal TTFB) with the flexibility of SSR (content can be updated without a full rebuild). It is particularly well-suited for large content sites where SSG build times become prohibitive and SSR cost is a concern.

// Next.js ISR configuration (App Router)
export const revalidate = 3600; // Regenerate every 1 hour

// Or with on-demand revalidation
import { revalidatePath } from 'next/cache';
revalidatePath('/blog/[slug]', 'page');

Hydration is the process of attaching JavaScript event handlers to server-rendered HTML after the page loads. Full hydration (the React and Vue default) downloads the entire JavaScript bundle and re-runs the component tree to attach interactivity — even for components that are purely static.

The hydration INP problem

Full hydration creates long tasks during the hydration phase — the browser parses and executes potentially megabytes of JavaScript immediately after the page becomes visible. This is a primary source of poor INP on SSR React applications — the page looks loaded but is unresponsive during hydration.

Partial hydration and islands architecture

Partial hydration (React Server Components, Astro islands, Qwik's resumability) only hydrates interactive components — static content receives no JavaScript overhead. A blog post with a comment form only hydrates the comment form component, not the post content, header, or footer. This can reduce JavaScript execution by 60–90% and dramatically improves INP on content-heavy pages.

Authentic Sources