Hydration Cost
The gap between visible and interactive, and the JavaScript that closes it.
5 to work through
-
intermediate Multiple choice
An article page is server-rendered React. Field p75 interaction to next paint is 420 ms on mid-range Android and the main thread is busy for roughly 1.9 seconds after the HTML arrives. Three widgets account for most of the client bundle - a comment thread a video player and a recommendation carousel. Fewer than 5% of readers open comments. Which change gets interaction to next paint under 200 ms with the least risk?
2 min answer -
advanced
A marketplace's pages paint quickly and feel unresponsive for several seconds after appearing. What is happening and how do you fix it?
1 min answer -
advanced
A page renders quickly and is unresponsive to input for several seconds on a low-end device. What is happening?
2 min answer -
advanced
A page renders quickly but is unresponsive for several seconds after appearing. What is happening, and what are the architectural responses?
2 min answer -
advanced
A server-rendered page uses islands: static HTML with independently hydrated interactive components. In production, one island's hydration throws because a third-party script mutated the DOM before React attached. What does the user see, and what stops it?
3 min answer
4 terms in this topic
Hydration
The browser attaching interactivity to server-rendered HTML by re-running component logic, during which the page looks ready and is not.
patternIslands Architecture
Rendering a page as static HTML with independently-hydrated interactive regions, so JavaScript is shipped and executed only for the parts that need i…
patternPartial Hydration
Attaching client-side interactivity only to the components that need it, rather than reconstructing the whole page's component tree in the browser.
metricTime to Interactive Gap
The interval between a page appearing complete and actually responding to input, during which the user's taps do nothing.
Neighbouring topics
Frontend & Experience Architecture
General material on architecting the surface the user actually touches.
Rendering Strategies
Client, server, static and incremental rendering, and what each costs on first paint.
Edge Rendering
Running the render close to the user, and the personalisation and cache trade it implies.
Micro-Frontends
Independent deployment of UI slices, and the shared runtime that undermines it.
Module Federation
Loading code from another build at runtime, with versioning and failure to think about.
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
Design Systems
Components as a versioned internal product, with adoption and deprecation like any API.
Component Contracts
Props, slots and events as an interface, and the breaking change hidden in a style.
Client State Architecture
Server state, UI state and derived state, and why conflating them causes most bugs.
Client Caching & Data Layer
Stale-while-revalidate, invalidation and optimistic updates on the client.
BFF for Experience
One backend per experience, shaped by the screen rather than by the domain.
API Shapes for UI
REST, GraphQL and RPC judged by over-fetching, round trips and client coupling.
Web Performance Budgets
A number a build can fail against, rather than a performance sprint once a year.
Core Web Vitals
LCP, INP and CLS — what they measure, and the architecture that moves them.
Accessibility Architecture
Semantics, focus management and announcements designed in rather than audited in.
Internationalisation
Locale, direction, pluralisation and dates as structural concerns, not string tables.
Client Feature Flags
Flag evaluation on a device you do not control, and the flicker and staleness it brings.
Real User Monitoring
Field data from real devices and networks, against the synthetic run that looked fine.
Frontend Security
CSP, XSS, CSRF, token storage, and the trust boundary that ends at the browser.