Frontend Architecture
Code splitting: fix the waterfall
Reading about over-splitting is not the same as pulling a page out of a waterfall. Take a real app, drive it into the failure mode on throttled 4G, then re-architect the chunk graph with the unit’s decision tree — measuring at every step instead of trusting the analyzer.
Turn the unit’s mental model into a reproducible engineering loop: profile the chunk graph under field conditions, find the waterfall and the over-splits, re-split per route, defer only heavy off-first-paint components, add the right resource hints, stabilise the vendor chunk, and verify the Core Web Vitals win with before/after numbers.
Take a multi-route SPA (your own, or build a small one) that is either over-split into a request waterfall or under-split into one giant bundle, and re-architect its chunk graph so LCP on throttled 4G drops under 2.5s and CLS under 0.1 — proving each change with measurements, not the bundle analyzer.
- A before/after table measured under identical throttled-4G conditions: LCP, CLS, INP, initial-route JS bytes, and the number of sequential chunk requests on the critical path.
- The network waterfall after the change shows the critical chunks fetched in parallel with the document (via preload) rather than discovered sequentially, with the waterfall depth visibly reduced.
- LCP is under 2.5s and CLS under 0.1 on throttled 4G, and no above-the-fold component flashes a Suspense fallback.
- A diff of two builds proving the vendor chunk's content-hashed URL is unchanged after a trivial app-code edit, plus a one-paragraph write-up naming which lever fixed each problem and why.
- Add a route-prefetch-on-hover layer for the whole nav and measure the click-to-interactive improvement on the prefetched routes versus cold ones.
- Compress-test the chunking: split one shared asset two ways (few larger vs many tiny chunks) and compare total transferred (compressed) bytes to quantify the compression penalty of over-splitting.
- Add a CI Lighthouse-CI gate that runs on throttled 4G and fails the build if LCP, CLS, or initial-route JS regresses past the budget.
- Repeat the experiment under HTTP/1.1 versus HTTP/2 and document how the waterfall's cost changes, confirming multiplexing helps parallel requests but not the sequential discovery chain.
This is the loop you will run on every real splitting decision: measure under field conditions first (throttled 4G, not the analyzer), classify every chunk as route / heavy-deferred / over-split, re-split per route by default, defer only heavy off-first-paint widgets, add preload for critical and prefetch for likely-next, and stabilise the vendor chunk so deploys do not bust the cache. Proving the LCP and CLS win with before/after numbers on a toy app makes the production version muscle memory — the chunk graph is a budget you design, not a number to minimize.