Frontend Architecture
Code splitting: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the splitting decision tree stick.
Reconstruct the unit’s spine — why splitting is a latency trade, the route-vs-component rule, the request waterfall, the vendor-chunk cache trap, and the preload/prefetch split — without looking back at the overview.
- 01Why is code splitting a latency trade rather than a free size cut?
- 02Why is route-based splitting the safe default while component-level splitting is a scalpel?
- 03Explain the request waterfall and why HTTP/2 multiplexing does not save you from it.
- 04How does isolating a vendor chunk help caching, and how does it accidentally backfire on every deploy?
- 05When do you use rel=preload (modulepreload) versus rel=prefetch for a chunk?
- 06Why is lazy-loading an above-the-fold component a classic production accident, and which Core Web Vitals does it attack?
If you could reconstruct each answer from memory, you hold the unit’s spine: splitting trades one download for many requests, so the metric is sequential round trips added, not bytes saved. Route-based splitting is the bounded, high-leverage default; component-level is a scalpel for heavy, off-first-paint widgets only. The waterfall is what loses on mobile and HTTP/2 cannot save it; a content-hashed vendor chunk with the runtime split out keeps caches warm across deploys; and preload defends current-critical chunks while prefetch warms likely-next ones — never lazy-load above the fold.