A server-rendered page shows its content in about a second, but clicks and taps do nothing for another two seconds. The trace shows one roughly 1.8 s main-thread task starting right after the JavaScript bundle finishes downloading. What is usually happening, and what are your options?

## Reading the symptom first The shape of this report is diagnostic on its own. **Visible early, usable late** means the rendering path is healthy and the JavaScript path is not. If the stylesheet were render-blocking or the server slow, nothing would paint at a second. If images were the issue, controls would still respond. A single long task starting exactly when the bundle finishes downloading points at one thing: everything the client does to take ownership of markup it did not create. ## What is inside that task Four distinct costs usually hide in one block: 1. **Compile and evaluate.** The engine must parse and compile the bundle before any of it runs, and top-level evaluation runs every module's side effects — registrations, singleton construction, polyfill installation. 2. **Framework bootstrap.** Building the initial component tree in memory. 3. **Hydration proper.** Walking the server-rendered DOM, matching it against what the client would have produced, and attaching event listeners and state. This scales with the *amount of markup*, not the amount of code. 4. **Initial state deserialization.** Server-rendered pages usually embed the data used to render, so the client does not refetch it. On a data-heavy page this blob can be hundreds of kilobytes. ## Confirming which one dominates Do not guess — the fixes are different. In a trace, script compilation and evaluation appear separately from the function calls that follow, and the state parse shows up as its own block. In the field, frame-level performance entries can name the script and function that dominated. `performance.mark` and `performance.measure` around your own bootstrap phases give you the split cheaply and work everywhere. ## The embedded-state detail One concrete and frequently-missed win: how the initial state is embedded. A large JavaScript object literal inside an inline script must be handled by the full JavaScript parser, with all its ambiguity. The equivalent data as a JSON *string* passed to `JSON.parse` uses a far simpler grammar and is typically several times faster for large payloads. The change is mechanical: ```html <script type="application/json" id="state">{"user":{"id":7},"items":[]}</script> <script> window.__STATE__ = JSON.parse(document.getElementById('state').textContent); </script> ``` It costs nothing and can take a meaningful bite out of a large blob's parse time. It does not make the payload smaller, though — that is a separate conversation about sending only the fields the first view needs. ## Options, in order of payoff **Ship less JavaScript to this route.** The most reliable fix. Everything in the initial payload gets compiled and evaluated whether or not the first view uses it. Route-level splitting and moving rarely-used features behind dynamic loading directly shrink both the compile and the evaluate cost. **Hydrate less.** Most pages are mostly static. Architectures that hydrate only interactive regions — islands, partial or selective hydration, depending on your framework's vocabulary — cut hydration cost roughly in proportion to how much of the page is genuinely interactive. This is a structural change, not a flag, and it is usually where the big wins are on content-heavy pages. **Defer what is not needed yet.** Regions below the fold do not need to be interactive at first paint. Deferring their hydration until they scroll into view, or until the main thread is idle, removes their cost from the blocking window entirely. **Shrink the state payload.** Send only what the first render needs and fetch the rest afterwards. Halving the blob halves its parse cost and its transfer cost at once. **Break up what remains.** If a large bootstrap is unavoidable, splitting it so the browser can dispatch input between pieces converts a dead page into a slow one — a real improvement in perceived responsiveness, though it does not reduce total work. ## What will not help Be explicit about this in an interview, because it is where weak answers go: - A **CDN** or **better compression** changes when the bytes arrive. The task starts after the download either way and takes the same time. - **`defer` or `async`** on the script tag moves the work; it does not shrink it. On a page whose paint already succeeded, it changes very little. - **A faster server** improves the time to first paint, which was never the complaint. - **Preloading the bundle** makes the CPU work start *sooner*, which can look better on a load metric and feels identical or worse to a user who is trying to click. ## The honest ceiling Sometimes the answer is architectural: if a page is fundamentally a document with two interactive widgets, paying full client-side bootstrap for it is the wrong design, and no amount of tuning inside that 1.8 s task will fix it. Saying so — and quantifying what a different approach would cost — is the senior part of this answer.