SSR, CSR and Hydration: performance and energy trade offs explained

How SSR CSR and hydration differ in practice

Server side rendering means the server builds the full HTML for a page and sends that markup to the browser. The browser can show meaningful content quickly because the document already contains rendered elements. Interactive behavior often still requires JavaScript to be downloaded and executed.

Client side rendering means the server sends a minimal HTML shell and the client downloads JavaScript that builds the DOM and inserts content. The initial HTML might be almost empty, so visual content appears only after the client has parsed and executed scripts.

Hydration is the process of taking server rendered HTML and attaching client side JavaScript to make the page interactive. Hydration reuses the HTML for initial paint and then runs client code to wire up event handlers and state. Hydration can be full or partial depending on whether every component needs client side runtime.

What happens on the network and on devices

Three resources determine observable behaviour and energy use: network transfer, server compute, and client compute. Each rendering approach moves work between server and client in different proportions.

Server side rendering pushes rendering compute to the server and sends ready to render HTML over the network. Client side rendering sends less initial HTML but larger JavaScript bundles that the client must download and execute. Hydration adds client CPU and memory cost because JavaScript must parse, execute and reconcile with existing DOM nodes.

Performance trade offs to consider

Low latency to first meaningful paint generally favours server rendered HTML because content can be displayed before heavy JavaScript finishes. High interactivity without repeated server round trips can favour client side rendering because the client holds application state and can respond locally.

Hydration gives the best of both worlds for many use cases: fast first paint from server HTML and rich interactivity once client scripts run. The trade off is the cost of hydrating. Hydration can require parsing large bundles, running framework bootstraps and walking the DOM to attach listeners. That work increases time to interactive and consumes CPU and battery on client devices.

Why these differences matter for energy

Energy consumption tracks compute and network activity. On the client, parsing and executing JavaScript and manipulating the DOM are CPU intensive and cause additional power draw on devices. On the server, rendering HTML consumes CPU and memory inside hosting infrastructure which in turn uses energy. Network transfer also carries embodied energy because routers, switches and transmission systems consume power to move bytes.

Choosing where to place work affects where energy is consumed. Moving rendering from client to server can reduce energy use on constrained mobile devices but shift energy to hosting. The overall effect depends on cache hit rates, user device baseline power characteristics, how many users share server resources and the efficiency of the hosting environment.

Common patterns that change the balance

Streaming server rendering progressively sends HTML so the browser can paint earlier while server continues to render remaining parts. Streaming reduces time to first paint without waiting for full server work to complete.
Partial hydration hydrates only interactive islands of the page while leaving static parts inert. This reduces client parsing and execution compared to full hydration.
Prerendering generates static HTML at build time and serves it from cache. This eliminates most server compute for each request and delivers fast HTML with small server cost per request.
Server components move component rendering entirely to the server for parts that do not require client runtime, reducing the need for hydration for those parts.

Deciding which approach to use

Match the rendering approach to the page intent. Use server rendering or prerendering when fast content paint and search engine indexing are primary goals. Use client rendering when the app is highly interactive and most state lives on the client. Prefer hydration with careful control when you need both fast paint and client side interactivity.

Evaluate the user population. If a large share of users are on low powered mobile devices or slow networks, prioritise reducing client side CPU and bundle size. If users mostly have powerful devices and the app needs complex client logic, client rendering can be sensible.

Practical optimisations to reduce energy and improve perceived speed

Reduce initial JavaScript by splitting bundles and deferring non essential code so the browser can render and hydrate sooner.
Adopt partial hydration or islands to hydrate only components that need interactivity. Static content does not carry hydration cost.
Cache aggressively at the CDN level for HTML when possible. Prerendered pages served from cache avoid per request server compute and reduce overall energy per visit.
Stream HTML so the browser begins painting content before the whole page arrives. This reduces perceived latency without requiring more client work.
Measure and tune using performance metrics rather than assumptions. Focus on first contentful paint, largest contentful paint and time to interactive or similar metrics that reflect real user experience.

How to measure the effects reliably

Measure both client and server sides. On the client use Lighthouse, WebPageTest and real user monitoring to collect metrics for paint, interactivity and JavaScript execution time. Look at CPU busy time and main thread work to estimate device energy impact.

On the server collect CPU and memory usage, request latency and cache hit ratios. If you can, aggregate compute usage over time to estimate energy and cost under expected traffic patterns. Compare scenarios where rendering moves between server and client while keeping other variables constant.

Compare network transfer sizes for HTML and JavaScript. Reducing bytes can reduce energy consumed across the network and speed up downloads on slow links.

Decision checklist for engineers and product owners

Is fast initial content essential for first time visitors or SEO? Prefer server rendering or prerendering.
Does the page require complex client side state that cannot be delivered from the server efficiently? Consider client rendering or hybrid approaches.
Are many users on low powered devices or slow networks? Prioritise reducing client JS and hydration cost.
Can caching be used to serve HTML or API responses so server cost per request is minimal? If yes, server rendering with CDN caching is efficient.
Can you split interactivity so only small islands hydrate? If yes, partial hydration often improves energy and performance.

Implementation notes and gotchas

Hydration mismatches occur when server rendered markup and client rendering outputs differ. Mismatches force frameworks to rerender parts of the page which increases CPU and bandwidth. Ensure server and client render the same DOM for the hydrated parts.

Measuring energy directly on heterogeneous user devices is difficult. Use proxy metrics such as CPU busy time, JS parse and execution time, and network bytes as consistent indicators of relative energy cost when comparing approaches.

Remember that moving work to the server may reduce device energy but increase infrastructure energy. The best outcome balances user experience and operational efficiency. For many sites a hybrid approach that prerenders static content, server renders dynamic HTML and applies selective hydration yields strong results.

Next practical steps

Run an experiment on a representative page. Implement two variants: a server rendered version with hydration and a client rendered version that defers non essential scripts. Measure paint and interactivity metrics under simulated network conditions and on real devices. Track server CPU and cache hit rates for the server rendered variant. Use those measurements to choose the pattern that meets user experience goals while minimising unnecessary client work and server cost.