Browser & Frontend Runtime
Putting it together: multiple-choice review
Crux Cross-track synthesis MCQs over the whole browser chapter — relay-race chain, the hydration uncanny valley, three-track bottleneck reading, and the five canonical breaks.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole browser track — event loop, render pipeline, V8, workers, fiber, SSR/SSG, and Core Web Vitals collapsed into one page. Each one is a decision you make staring at a real trace, not a definition to recite.
Goal
Confirm you can connect every layer of the page-load relay into one chain: why the symptom routinely names the wrong layer, why hydration is the hinge, and which track is the constraint at the moment that matters.
Quiz
Completed
A server-rendered product page hits LCP at 1.4 s (good) but the first tap on 'Add to cart' at 2.0 s records INP 700 ms. What is the structural explanation?
Heads-up LCP measures when the largest element paints; INP measures interaction latency. They are independent — a fast paint over server HTML does not protect interactivity while hydration blocks the main thread.
Heads-up With a tap inside the hydration window, most of the 700 ms is input delay — time queued behind the long task — not handler processing time. Optimising a handler that was never the constraint moves nothing.
Heads-up The page already painted at 1.4 s, so the bytes arrived. A post-paint interaction delay is a main-thread problem (hydration), not a network one.
Quiz
Completed
A DevTools trace shows LCP firing late while the hero image is still on the network track at the LCP moment. Which layer is the actual cause, and which is paying for it?
Heads-up If the image is still downloading at LCP time, the compositor never got it. The pipeline is fine; the failure is that discovery happened too late on the parse layer.
Heads-up Render-blocking JS is the other branch — hero finished early but the main thread is busy. Here the hero is still on the network track, so the constraint is discovery, not V8.
Heads-up A resource still downloading at LCP time is a network-track symptom rooted in discovery. The GPU composites only what already arrived and was painted.
Quiz
Completed
The 'Add to cart' re-render that should cost ~5 ms costs ~80 ms and tanks INP, even though the bundle is small and the handler is short. What is the most likely cross-layer cause?
Heads-up The reconciler walked the same tree fast elsewhere. An 80 ms re-render with a small handler points at a megamorphic V8 path, not the reconciler — this is the classic 'React is slow' misattribution.
Heads-up A synchronous re-render cost on the main thread is not a network event. A data fetch would show on the network track while the main thread is free, not as scripting time inside the interaction.
Heads-up CLS measures visual stability, not interaction latency. An 80 ms scripting bar inside the tap is an INP problem caused by slow execution, not a layout shift.
Quiz
Completed
A deploy ships new HTML and a new JS bundle, but a fraction of returning users hit runtime errors and some are stuck on a broken page even after the fix deploys. What is the canonical break and the layer?
Heads-up A mismatch flashes content and spikes CLS within a session; it does not survive a deploy or trap users on old code. Persisting across deploys and bypassing the fix is the signature of a stale worker cache.
Heads-up The new bundle deployed fine; the problem is a client-side cache (the service worker) serving the OLD bundle against new HTML. A CDN flush would not free users trapped behind their own worker.
Heads-up Megamorphism hurts INP, not correctness across deploys. Runtime errors from a version skew plus users trapped on a broken shell is statefulness — the cache outlived its correctness.
Quiz
Completed
A junior optimises the 'Add to cart' handler from 12 ms down to 6 ms; field INP stays at 480 ms. What did the three-track method say they should have done first?
Heads-up Handler processing time was never the constraint. INP held at 480 ms because the tap queues behind the hydration long task; no amount of handler optimisation touches that input delay.
Heads-up CSR removes hydration but reintroduces a blank first paint and a worse LCP and SEO — trading one problem for two. The fix is shrinking what hydrates (code-split, Server Components, islands), not abandoning SSR.
Heads-up Hydration is largely a single long main-thread task; extra cores do not split it. The lever is less to parse, compile, and execute — a smaller bundle and fewer hydrated islands.
Quiz
Completed
One RUM session is poor on every metric: TTFB 2980 ms, LCP 6800 ms (hero is a CSS background-image), INP 540 ms (LoAF names the hydration script), CLS 0.21 (price re-rendered). Which single fix has the most leverage to start with, and why?
Heads-up CLS is a real bug, but fixing the price mismatch leaves a ~3 s TTFB floor untouched. Leverage is about how many downstream metrics depend on a fix, and FCP and LCP both sit on top of TTFB.
Heads-up A skeleton hides the wait but moves no metric — the main thread is still blocked and the bytes still arrive at 2980 ms. It treats perception, not the constraint.
Heads-up INP matters, but its root here is the hydration long task downstream of the bundle. With a 2980 ms TTFB, paint cannot even start for ~3 s; fixing the floor cascades to FCP and LCP, so TTFB is the higher-leverage first move.
Recap
The through-line across the track is one chain: TTFB is the floor, discovery feeds LCP, V8 parse plus the reconciler feed the hydration long task, and that long task is the hinge that determines early INP. The symptom routinely names the wrong layer — ‘slow image’ is discovery, ‘React is slow’ is a megamorphic V8 shape, ‘broken after deploy’ is a stale worker cache. The discipline is always the same: measure before touching, find the constraint track at the constraint moment, fix the dominant cause (TTFB and hydration cost first), then re-measure.