Rendering modes at a glance
Server side rendering
Server side rendering means HTML is produced on the server and delivered to the browser already populated with content. The browser can render useful pixels immediately without running large amounts of JavaScript. Interactivity that requires JavaScript may be added later, but the initial document is usable on arrival.
Client side rendering
Client side rendering means the server returns a small HTML shell and the browser downloads JavaScript that constructs the full user interface in the client. Rendering of meaningful content waits for script download parse and execution. This model centralizes rendering logic in the browser and often reduces server complexity at the expense of upfront client work.
Hydration
Hydration is the process of attaching interactive behavior to HTML that was rendered on the server. The browser has markup and styles already but needs to run JavaScript to bind events reconcile virtual DOM or initialize component state. Hydration sits between pure server side rendering and pure client side rendering because the document is visible but interactivity depends on client execution.
Where time and energy are spent
Network transfer
Bytes transferred affect both perceived speed and device energy. Larger JavaScript bundles add network cost for both download and subsequent work. Server side rendering can shift some work off the network by returning HTML directly but may still require scripts for interactivity. Minimizing unnecessary bytes remains essential regardless of rendering mode.
Client CPU and main thread time
On the client the expensive factors are parse compile and execute time for JavaScript and layout and paint work triggered by DOM operations. Long main thread tasks block input and increase battery drain because the CPU stays active longer. Hydration often concentrates work into a short window when the framework reconciles nodes and registers listeners. Client side rendering tends to spread parse and execution across building the entire UI from scratch.
Server compute and scalability
Generating HTML on the server uses CPU and memory at the origin or edge. For pages with high traffic and little personalization, static HTML generation or cached server rendered pages reduce repeated compute. For personalized content server rendering may increase server load compared with serving a static shell and shifting personalization into client code. Server costs translate to operational energy use and financial cost, so they matter for architecture decisions.
How to measure impact in a way that guides decisions
Comparing rendering modes requires both lab controlled measurements and real user monitoring. Lab tools help isolate technical differences while real user data reveals the distribution of device classes network conditions and session patterns that determine real impact.
- Define representative pages and user journeys
Pick a small set of pages or flows that reflect your product intent. Include both content heavy pages where first render matters and interactive flows where Time to Interactive is critical.
- Collect lab metrics
Use a controlled tool such as Lighthouse or WebPageTest to gather First Contentful Paint Largest Contentful Paint Time to Interactive Total Blocking Time and script parse or compile time. Run tests across a set of synthetic conditions that mirror your audience for example slow 4G low end mobile and a typical desktop profile.
- Measure client CPU work and long tasks
Record main thread usage and Long Tasks API events. In Chrome DevTools the Performance panel isolates scripting layout and painting durations. Capture the duration and frequency of long tasks that arise during hydration or initial client rendering.
- Gather real user monitoring data
Instrument the application with PerformanceObserver and collect metrics such as navigation timings long tasks and cumulative layout shift. Segment results by device class user connection and geography so you know which cohorts see the most client work.
- Estimate energy using models
Direct battery measurements at scale are rare. Instead estimate relative energy by combining main thread CPU time with published power profiles for representative devices or the device battery discharge rate when available. Use this only for comparative analysis not absolute claims.
- Compare total user perceived time and server cost
Pair client side metrics with server CPU and memory usage measurements. For each rendering mode compute median and tail values for user perceived metrics and the server cost per request under realistic cache hit ratios.
Patterns that reduce hydration cost
Partial hydration and islands architecture
Partial hydration isolates interactive pieces and hydrates only those parts of the page. An islands model renders static content on the server while small interactive islands hydrate independently. This approach reduces immediate main thread pressure and network costs because only the JavaScript necessary for each island is executed when that island becomes relevant.
Progressive and lazy hydration
Progressive hydration breaks the hydration work into smaller units and schedules them to run after the page is usable. Lazy hydration defers non essential components until interaction or until the browser is idle. Both techniques reduce peak main thread utilization and improve perceived responsiveness on constrained devices.
Event driven hydration and on demand boot
Event driven hydration attaches minimal event handlers that boot full component logic only when the user interacts in a way that requires it. This pattern is effective on pages with many optional interactive widgets where most users do not use all widgets during a session.
Server components and zero JavaScript rendering
Server component approaches move as much rendering and logic back into the server as possible and stream rendered fragments to the client. When interactivity is minimal or limited to a few areas this can eliminate the need for large client frameworks and dramatically reduce client CPU and bytes.
Decision criteria and tradeoffs
When server side rendering is preferable
Choose server side rendering when initial content must appear quickly on low end devices when SEO matters or when users expect immediate readable content before interaction. Also prefer server rendering when personalization can be handled on the server without excessive compute per request.
When client side rendering is preferable
Choose client side rendering when your application is highly interactive with complex client side state where moving logic to the server would be costly or slow. Client side rendering centralizes code and can simplify deployment for single page applications where SEO and first paint are secondary to rich interactions.
When hydration makes sense and how to reduce its cost
Hydration is sensible when you need the best of both worlds: quick first paint with server rendered HTML and full client side interactivity. Reduce its cost by splitting bundles using code splitting deferring non critical features using partial hydration or by adopting server component patterns to remove the need to hydrate parts of the UI entirely.
Practical checklist before changing a rendering strategy
- Validate with real user data
Do not base a migration solely on lab numbers. Confirm that your most common devices and networks would benefit.
- Measure server cost under expected traffic
Model the origin compute increase or decrease and consider CDN and edge rendering options to balance latency and cost.
- Prototype the critical pages
Implement both approaches for a small sample and run A B tests to measure perceived performance engagement metrics and server load.
- Prioritize incremental improvements
Start by trimming bundles and instrumenting long tasks. Consider partial hydration before committing to a full architectural migration.
How to present results to stakeholders
Report both user centered metrics and operational cost. Show distribution plots not just averages. Include device and network segmentation and translate client CPU work into a relative energy estimate with a clear note about uncertainty. Provide a migration plan that targets the highest impact pages first and includes measurable success criteria such as median Time to Interactive reduction or decrease in long task time for low end devices.