Rendering pipeline visualizer

What the simulation shows

Each run draws the stages of one page load as bars on a shared timeline and lists them in a table. Two moments matter most in the summary: when meaningful content first appears, and when the page can respond to a tap or click. The distance between them is the period when a page looks ready but is not, which is the cost hydration adds to server-rendered pages (source 1).

The five strategies follow the definitions in Google's guide to rendering on the web (source 1):

• Client-side rendering. The server sends a small shell; the browser downloads and runs JavaScript, fetches data and builds the page. Content and interactivity arrive together, but late.
• Server rendering with full hydration. The server builds HTML per request, so the first byte takes longer, but content paints as soon as the HTML arrives. JavaScript then hydrates the whole page.
• Static generation with full hydration. Like server rendering, but the HTML was built ahead of time, so the first byte is fast and steady.
• Streaming with selective hydration. The server sends HTML in chunks as it is ready, and the framework hydrates the most important parts first and the rest later in smaller pieces.
• Islands. The page is HTML with a few interactive components, and only those load JavaScript and hydrate (source 2).

The assumptions behind the model

So that you can check or reproduce the numbers by hand, here is exactly how the model works.

Each device profile sets four values: the time to first byte for a dynamic response and for a static or cached one, the time to download 100 KB, and a CPU factor that multiplies all script work. The laptop profile uses a CPU factor of 1, the mid-range phone 4 and the low-end phone 6. The factor of 4 echoes the CPU slowdown Lighthouse applies when it simulates a mobile device; the others are round numbers for comparison, not measurements of particular phones.

Each strategy sets how much JavaScript ships and how much hydration work it needs. Client rendering and full hydration ship 320 KB in the model, streaming ships 240 KB and islands 60 KB. Evaluating 100 KB of script costs 12 ms times the CPU factor. Full hydration costs 110 ms times the CPU factor; streaming hydrates 35 percent of that first and the rest after a short pause; islands hydrate for 22 ms times the CPU factor. Client rendering adds a data request and a 70 ms render, again scaled by the CPU factor.

These figures were chosen to make differences visible, not to match any framework or app. Real costs vary widely with code size, component count, data and device.

How to read the results

• A long bar for JavaScript evaluation means start-up code is heavy. Splitting code by route and loading features on demand shortens it.
• A long hydration bar after an early paint means users may tap a page that cannot answer yet. Hydrating less, later or in pieces narrows that gap; our hydration guide covers the options.
• A late paint with client rendering means users wait on a blank or skeleton screen. Server rendering or static generation of key routes moves content earlier in this model.
• When server response dominates, the bottleneck is on the server or network side, and frontend changes alone will not fix it.

Limits of a simulation

The model leaves out many things that matter in real apps: CSS and font loading, image downloads, third-party scripts, network contention between requests, caching on repeat visits, and the fact that real hydration is spread across many tasks rather than one block. It also treats each stage as happening once. For your own app, record a trace in the Chrome DevTools Performance panel on a throttled CPU, or ask us for a rendering analysis.

Privacy

The visualizer runs only in your browser. It makes no network requests, stores nothing and sets no cookies.