Frontend Architecture
Code splitting: multiple-choice review
Crux Multiple-choice synthesis across the code-splitting unit — the latency trade, route vs component splitting, the request waterfall, vendor-chunk caching, and resource hints.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None ask for a definition — each mirrors a splitting decision you make under a real latency budget, where the wrong call regresses LCP or re-downloads React on every deploy.
Goal
Confirm you can connect the latency trade, the route-vs-component rule, the request waterfall, vendor-chunk caching, and resource hints — the synthesis the overview built toward.
Quiz
Completed
A team wraps every panel of a dashboard in React.lazy. The analyzer shows 40 chunks, none over 12 KB, yet field LCP on 4G regresses from 2.3s to 4.1s. What is the dominant cause?
Heads-up Splitting did not add code — the same modules are now in more files. The regression is round-trip latency from a sequential waterfall plus lost compression, not extra bytes.
Heads-up Parse cost scales with total bytes, not file count. The dominant cost on a 4G phone is sequential round-trip latency, which is why the same build is fine on desktop.
Heads-up The analyzer is correct about size. Smaller-on-disk is not faster-on-network when each chunk is a request and the requests are dependent — that is the entire premise of the unit.
Quiz
Completed
You can split exactly one thing on a page. Which candidate is the highest-leverage, lowest-risk split?
Heads-up Splitting an above-the-fold component buys a round trip and a spinner to save almost nothing, hurting LCP and risking CLS. Ship small above-the-fold content in the route chunk.
Heads-up Over-splitting shatters the graph into a sequential waterfall and destroys compression. The rule is split heavy, off-first-paint things — not everything.
Heads-up React is needed for first paint, so deferring it just adds a round trip to the critical path. React belongs in a long-cached vendor chunk, not a lazy boundary.
Quiz
Completed
A reviewer claims 'HTTP/2 multiplexing makes bundling obsolete, so split as granularly as you like.' Where is this wrong?
Heads-up Multiplexing only helps requests the browser knows about at the same time. A waterfall is sequential by construction, and tiny files compress worse — both costs survive HTTP/2.
Heads-up HTTP/2 does multiplex many parallel requests over one connection — that part of the claim is right. The flaw is sequential discovery and lost compression, not parallelism.
Heads-up Not always — route-based splitting still wins by keeping the initial route lean. The point is to find the middle: n chunks where n is far less than your module count, not to shatter or to ship one giant file.
Quiz
Completed
Returning users re-download React on every deploy even though dependencies never changed. Most likely cause?
Heads-up That is the symptom of bad chunking, not a design rule. A properly isolated, content-hashed vendor chunk stays cached across deploys while its bytes are unchanged.
Heads-up Caches key on URL. With content-hashed filenames an unchanged vendor chunk keeps the same URL and stays cached; the hash is changing because something volatile leaked into it.
Heads-up Size does not block caching here. The defect is hash volatility — pull the runtime into its own tiny file so vendor's bytes stay stable across deploys.
Quiz
Completed
A 180 KB interactive viewer sits below the fold and opens only when the user scrolls to it. Best loading strategy for a 4G audience?
Heads-up That puts 180 KB most visitors never scroll to onto the LCP critical path, inflating parse and TTI for everyone to avoid one spinner. A heavy, below-the-fold, interaction-gated widget is the canonical thing to defer.
Heads-up Splitting the above-the-fold header adds a round trip and spinner to first-paint content and builds a sequential waterfall. Split the heavy deferred thing; do not shatter the page.
Heads-up An iframe is a separate document with its own JS context and load cost, not a chunk-strategy tool. The viewer is a component — split it as one and pre-empt the waterfall with a prefetch.
Quiz
Completed
What is the practical difference between rel='preload' (or modulepreload) and rel='prefetch' for chunks?
Heads-up Priority and intent differ. preload is high-priority for a chunk the current page needs; prefetch is idle-priority speculation for a future navigation. Using prefetch for a critical chunk leaves it discovered too late.
Heads-up Both apply to script/module chunks (modulepreload for ES modules). The split is current-page-critical vs likely-future, not by asset type.
Heads-up Neither blocks rendering — both are hints. prefetch is the low-priority speculative one; preload is the high-priority current-need one. Reversed from the claim.
Recap
The through-line of the unit is one decision tree: splitting is a latency trade, not a free size cut, so the question is always how many sequential round trips you added to the critical path. Split per route by default (bounded waterfall, framework default); split a component only if it is heavy and off the first paint; never split small above-the-fold content. The waterfall — not byte count — is what loses on 4G, and HTTP/2 does not save it. Defend caching with a content-hashed vendor chunk and the runtime split out, and use preload for current-critical chunks, prefetch for likely-next navigations.