Performance
Bundle budgets: multiple-choice review
Crux Multiple-choice synthesis across the bundle-budgets unit — the four-phase cost model, Core Web Vitals levers, splitting vs compression, third-party tax, and CI enforcement.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make in a real perf review — not a definition to recite, but which lever actually moves the number under load.
Goal
Confirm you can connect the four-phase cost model, Core Web Vitals thresholds, the splitting/tree-shaking/compression hierarchy, the third-party tax, and CI enforcement — the synthesis the individual lessons built toward.
Quiz
Completed
Team A ships brotli instead of gzip and cuts transfer from 180 KB to 150 KB. Team B code-splits the same route from 600 KB to 200 KB uncompressed. Both report LCP wins. Which team actually reduced CPU cost, and why?
Heads-up Compression is a transport-layer win only. The engine parses the decompressed bytes, so the CPU cost is set by uncompressed size — unchanged by brotli.
Heads-up Brotli is an encoding; V8 receives raw decompressed bytes and parses them identically regardless of how they arrived. No parse speedup.
Heads-up On a fast TTFB, LCP past 2.5 s is usually JS parse/execute blocking paint. CPU is exactly the bottleneck the unit targets.
Quiz
Completed
A page loads in 800 ms on the developer's M-series laptop but sits blank for ~8 s on a mid-range Android. TTFB is 70 ms on both. What is the dominant cause?
Heads-up TTFB is 70 ms on both, so the network delivered the first byte fast. The gap is CPU-bound parse/compile/execute, not download.
Heads-up TTFB is identical at 70 ms. The server is not the variable; the client CPU is.
Heads-up Compression affects download bytes. An 8 s blank screen on fast TTFB is the CPU parsing/executing a large uncompressed bundle.
Quiz
Completed
A team's P75 LCP is Poor but P75 CLS is Good. They cut the route bundle from 700 KB to 200 KB. LCP and INP improve; CLS barely moves. Why is that the expected outcome?
Heads-up CLS measures visual stability (viewport fraction × shift distance), not CPU cost. Reducing bytes does not reserve layout space.
Heads-up Unchanged CLS is correct: the fix for CLS is sized images, reserved space, and font-display: swap — none of which a bundle cut touches.
Heads-up CLS is a client-side layout discipline issue; SSR alone does not fix unsized media or late fonts.
Quiz
Completed
A developer writes `import { debounce } from 'lodash'` and the analyzer shows 70 KB, not 2 KB. They already set `sideEffects: false` on their own package. What is the actual cause and fix?
Heads-up `sideEffects: false` on your package only marks your code shakeable; it cannot make a third-party CJS module statically analysable.
Heads-up Minification renames and strips whitespace; it does not remove unreferenced CJS exports. Tree shaking requires statically-analysable ESM.
Heads-up Compression shrinks the transfer of those bytes but they still ship, still parse, and still execute. The fix is to not include them.
Quiz
Completed
An app spends a sprint cutting its first-party bundle from 800 KB to 350 KB; a month later the data team adds Segment, Hotjar, and Intercom (~450 KB) via GTM and the win is erased. Which control would have caught this before it shipped?
Heads-up size-limit measures chunks in your build output. GTM-injected scripts load from external domains at runtime and never appear in your bundle, so the gate is blind to them.
Heads-up You do not control vendor source and cannot shake it; vendors ship full feature sets. Tree shaking is a first-party, ESM-only mechanism.
Heads-up Compression cuts transfer, not the main-thread parse/execute the vendor scripts impose. The control needed is governance, not compression.
Quiz
Completed
Lighthouse CI on every PR reports P75 LCP 2.1 s; production RUM shows 4.8 s P75 on mobile for the same route. A senior reads this as:
Heads-up A 2×+ synthetic-vs-field gap is normal and reflects real device/network diversity, not misconfiguration.
Heads-up Lighthouse catches code-introduced regressions pre-merge cheaply; RUM catches what synthetic misses post-deploy. They cover different failure classes.
Heads-up RUM revealing a worse real number is a reason to cut bytes, not to accept the regression as baseline.
Recap
The unit’s through-line is one decision tree: bytes equal four CPU phases (download is network, parse/compile/execute are the user’s CPU), so the real levers reduce shipped bytes — splitting first, then tree shaking, with compression as a transport-only finisher. Core Web Vitals quantify the cost (LCP/INP move with JS, CLS does not). Third-party scripts are the silent budget killer that first-party gates cannot see, so they need their own budget plus CSP. And none of it holds without enforcement: size-limit in CI, RUM in production, a ratcheting budget-raise protocol against drift.