A page renders quickly but is unresponsive for several seconds after appearing. What is happening, and what are the architectural responses?

What is happening

Server-rendered HTML arrives and paints quickly — and it is inert. The framework must then download the JavaScript bundle, parse it, execute it, and re-run the component tree on the client to attach event handlers and rebuild internal state. That is hydration.

During it, the page looks finished and does nothing. Clicks are dropped or queued, inputs do not respond, and the user's experience is worse than a slower page that was honest about loading — because the visual completeness sets an expectation the page cannot meet.

The cost scales with the amount of JavaScript and with the size of the component tree, and it is paid on the user's device, so it is dramatically worse on mid-range mobile hardware than on the developer's machine. The gap between developer experience and user experience is larger here than almost anywhere else in web engineering.

The architectural responses

• Ship less JavaScript. The most direct answer and the least popular: audit the bundle, remove unused dependencies, replace heavy libraries, and question whether each interactive component needs a framework at all.
• Islands architecture — the page is static HTML with independently-hydrated interactive regions, so only the interactive parts carry JavaScript. This addresses the problem structurally rather than by optimisation, and it is why the approach has spread.
• Server components, where components render on the server and never ship their code to the client at all — the same principle applied within a single component model.
• Progressive and selective hydration, prioritising components in the viewport or those the user interacts with first, so the critical regions become interactive before the rest.
• Streaming server rendering, so HTML arrives in chunks and hydration begins on early parts while later parts are still rendering.
• Resumability, which serialises the necessary state into the HTML so the client resumes rather than re-executing — the strongest form, at the cost of a different framework model.

What to measure

Interaction-to-next-paint and total blocking time, on real devices in the field, not in a lab on fast hardware. First contentful paint looks excellent in exactly the situation this problem describes, which is why a strategy measured on paint metrics alone misses it entirely.

Segment field data by device class, since the aggregate is dominated by fast devices and the failure is concentrated in the slow tail — which is a large share of users in many markets.

The judgement

Interactivity delay is a function of how much JavaScript is shipped, and every architectural response is ultimately a way of shipping less. Frameworks, streaming and selective hydration change when the cost is paid and reduce it at the margin; the structural fix is that most of a typical page does not need to be interactive at all, and treating interactivity as opt-in rather than default is what produces order-of-magnitude differences.