Key Takeaways
- Choose rendering per page or route, based on content freshness, interactivity, crawlability, and measured performance.
- SSR delivers server-generated HTML, but hydration can delay JavaScript-powered interactions. Visible content and usable controls are different milestones.
- For shared content that can tolerate delayed updates, consider static generation and regeneration before adding request-time rendering.
- CSR can support navigation without full-page reloads, but it doesn't eliminate data requests or guarantee lower server costs.
Client-side rendering builds a page's interface in the browser using JavaScript; server-side rendering generates its HTML on the server. Neither is universally better. Choose according to what users need to see immediately, how fresh the content must be, and what must work after it appears.
Client-Side Rendering vs Server-Side Rendering: The Lifecycle
The useful distinction is where the initial page content comes from—not whether the application uses JavaScript.
- Client-side rendering (CSR): the browser receives an HTML shell, loads application JavaScript, and creates the interface. Content may require additional data requests.
- Server-side rendering (SSR): the server obtains the required data and generates HTML for the request. The browser can display that content without waiting for application JavaScript to render it.
- Static site generation (SSG): HTML is generated ahead of requests, typically during a build, then served as static files. Static pages can still include interactive JavaScript.
This schematic shows representative flows, not relative speeds. Downloads and data fetching can overlap.
CSR
request -> HTML shell -> JavaScript + data -> render content
SSR with hydration
request -> server data + render -> HTML content -> hydrate controls
SSG with optional interactivity
build: data + render -> saved HTML
request -> saved HTML content -> optional JavaScriptHydration: Visible Doesn't Necessarily Mean Interactive
Hydration connects client-side application logic to existing HTML, including the event handlers that power custom controls. A server-rendered page may therefore show its content before its JavaScript-powered buttons work. Ordinary HTML links and forms don't inherently require hydration.
Hydration also consumes browser CPU time. SSR with hydration doesn't automatically mean less client JavaScript. Keep interactive regions focused, and investigate hydration mismatches rather than hiding them: React expects the initial client output to match the server-rendered content.
What Level of User Interaction Will You Have?
Content-focused pages often benefit from delivering useful HTML immediately. Highly interactive applications often benefit from keeping interface state in the browser. Treat those as tendencies, not architectural rules: a news article can contain interactive charts, and a dashboard can start with server-rendered data.
Use these starting points, then validate them against your application's requirements:
| Page type | Strategy to evaluate first | Decision that matters |
|---|---|---|
| Blog, documentation, or news article | SSG with regeneration; SSR when freshness requires it | Define an acceptable publishing delay instead of assuming every request needs fresh rendering. |
| Product or category page | Static or cached public content, with dynamic availability and account features | Separate shareable content from user-specific data and freshness-sensitive values. |
| Authenticated dashboard or editor | CSR, or SSR for the first useful view followed by client updates | Compare first-use readiness with the quality of repeated interactions. |
| Social network | SSR or SSG for public profiles; evaluate CSR for private, frequently updated feeds | Choose separately for public discovery and logged-in interaction. |
Ask what must work on a direct visit, what can wait, and how much state must survive navigation. For a mostly read-only page, also question whether you need a large client framework; see our discussion of when not to use React.
CSR paired with a client router can avoid full-document navigations, but subsequent views can still fetch data from servers. Count actual requests and backend work rather than assuming that fewer document reloads means fewer server requests.
How Important Are Initial Load Times?
SSR can expose content before application JavaScript runs, but it doesn't guarantee a faster page. Server processing and network latency can delay HTML delivery; client JavaScript and hydration can delay usability afterward. A cached static page avoids request-time rendering altogether.
Measure separate outcomes instead of one vague “load time”:
- Time to First Byte (TTFB): the time from navigation start until the first response byte arrives—not when useful content becomes visible.
- Largest Contentful Paint (LCP): when the largest eligible visible content element is rendered.
- Interaction to Next Paint (INP): responsiveness to user interactions during the visit. It isn't a timestamp for when hydration finishes or every feature becomes usable.
- Task readiness: define an application-specific check, such as when a visitor can successfully open the navigation menu or submit a search.
Compare Equivalent User Journeys
- Test production builds with equivalent content, images, third-party scripts, and backend data.
- Use the same device and network conditions. Separate cold-browser visits, repeat visits, and client-side navigation.
- Label server or CDN cache hits and misses separately. Don't compare warmed static output with an uncached SSR request and call it a rendering benchmark.
- Record TTFB, LCP, and whether the primary action works when first attempted. Inspect JavaScript execution and hydration in a performance trace.
- Repeat tests, then validate the result with real-user measurements. Lab tests alone don't capture the full range of devices and interactions.
Application size alone doesn't determine performance. Examine the JavaScript actually downloaded and executed for each route, including third-party code; our JavaScript performance tips cover that side of the investigation.
Streaming SSR Changes Delivery, Not the Amount of Required Work
Streaming sends HTML progressively instead of waiting for the entire page to finish rendering. You can deliver the main content while slower sections are still loading, but sending a placeholder early doesn't make the missing content ready.
Choose loading boundaries around genuinely independent sections and plan for late failures. Once the response has started streaming, its HTTP status can no longer be changed. Check that your deployment path actually delivers chunks rather than buffering them.
SSG and Hybrid Rendering: Choose Where and When
Static Generation and Regeneration
If visitors receive the same article or documentation page, generating it for every request may be unnecessary. SSG moves that rendering work ahead of delivery; the trade-off is that published HTML needs an update mechanism when its source changes.
Incremental or on-demand regeneration updates generated content without rebuilding the entire site. For example, Next.js supports time-based and on-demand revalidation. Its documented time-based ISR flow can serve an existing stale page while a replacement is generated in the background, so a revalidation interval isn't a guarantee of exact content freshness.
Set an explicit freshness requirement. “An article correction must appear promptly” and “inventory must be checked before purchase” call for different update policies.
Rendering, Navigation, and Component Boundaries Are Separate
Hybrid rendering isn't just “SSR first, CSR afterward.” Frameworks can combine static generation, request-time rendering, and browser rendering across routes; navigation behavior is another choice. SvelteKit, for example, lets you configure rendering and prerendering for individual pages or groups of pages.
Component boundaries are a separate concern too. In the Next.js App Router, Client Components can contribute to the initial server-generated HTML and then hydrate in the browser. “Client Component” therefore doesn't mean “CSR-only page.”
Choose the lifecycle you need before choosing a label. “Isomorphic” describes shared server/browser code; it doesn't specify your caching, freshness, or navigation policy.
Does Server-Side Rendering Improve SEO?
SSR and SSG make content available in the HTML response without requiring crawler-side JavaScript execution. Google can render JavaScript, but rendering is queued, and not all bots execute it. That's a crawlability consideration—not a promise of better rankings.
For public pages, provide descriptive titles, metadata, consistent canonical URLs, crawlable links, and appropriate HTTP status codes. Prefer important metadata in the initial HTML, and don't replace an initial canonical URL with a conflicting client-generated value.
Identify the search and preview crawlers that matter to your audience, then test their actual output. Google's developer guidance recommends inspecting how Google sees your page; a successful render in your own browser isn't enough verification. Content quality, discoverability, and performance still require attention whichever rendering mode you choose.
Production Checklist
- Budget both sides: account for SSR compute and backend latency alongside client JavaScript transfer and execution. For a Node backend, investigate Node.js performance optimization rather than treating SSR as a substitute for backend work.
- Design caching deliberately: define which output is public, how it becomes stale, and how updates reach every serving layer.
- Protect personalized responses: shared caches can leak one user's content to another. The Cache-Control private directive restricts storage to private caches; no-store instructs caches not to store the response. Choose according to the data's requirements.
- Keep request state isolated: mutable server-side state shared across requests can expose one user's data to another request.
- Test failure paths: include slow data sources, failed regeneration, interrupted JavaScript loading, direct URLs, keyboard navigation, and late streaming errors.
Choose the simplest strategy that meets each route's requirements. Deliver shared content as generated HTML where practical, render dynamically when the request genuinely matters, and spend client JavaScript on interactions that earn its cost.
FAQ
What is the difference between client-side rendering and server-side rendering?
CSR creates the page's interface in the browser using JavaScript. SSR generates HTML on the server for the request; client JavaScript may then hydrate interactive features.
Is SSR faster than CSR?
Not automatically. SSR can display content before application JavaScript runs, but server latency and hydration can offset that advantage; compare TTFB, LCP, and successful use of the primary action.
Does SSR automatically improve SEO?
No. SSR makes content available without crawler-side JavaScript execution, but search visibility also depends on crawlability, useful content, metadata, and performance; SSG can provide the same initial-HTML benefit.
What is hybrid rendering?
Hybrid rendering combines strategies within an application, such as generated articles, dynamically server-rendered pages, and client-rendered dashboards. Rendering strategy, client-side navigation, and hydration are related but separate decisions.
What frameworks support both CSR and SSR?
Next.js, Nuxt, and SvelteKit support server and client rendering. Their configuration models differ: Nuxt supports route-specific rendering rules, while SvelteKit exposes page-level rendering options; verify deployment support for the particular combination you choose.
Further Reading
- Rendering on the Web — rendering terminology and performance trade-offs.
- React hydration reference — attaching application logic to existing HTML and handling mismatches.
- Web Vitals — user-visible metrics and lab versus field measurement.
- Google's JavaScript SEO basics — crawler rendering, metadata, canonical URLs, and status codes.
- Next.js incremental static regeneration — updating cached generated pages.
- Nuxt rendering modes — universal, client-side, and route-based hybrid rendering.
- SvelteKit page options — configuring prerendering, SSR, and client rendering.
- MDN HTTP caching guide — shared caches, personalized responses, and cache directives.
