Learn the vocabulary of breaking a bundle into chunks loaded only when a route or feature is actually needed.
0 / 5 completed
1 / 5
At standup, a dev mentions breaking a large JavaScript bundle into smaller chunks that are loaded on demand, such as only when a user navigates to a particular route, instead of shipping the entire application's code in one initial download. What is this technique called?
Code splitting is exactly this: it breaks a large JavaScript bundle into smaller chunks that a bundler generates at build time, loaded on demand, such as only when a user navigates to a particular route, instead of shipping the entire application's code in one initial download. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This load-only-what's-needed-when-needed approach is exactly why code splitting can shrink a large application's initial page-load size dramatically.
2 / 5
During a design review, the team applies code splitting per route in a large single-page application, specifically because loading only the current route's chunk on demand avoids shipping every other route's code in the initial page load. Which capability does this provide?
Code splitting here provides a smaller initial page-load size, since only the current route's chunk downloads immediately while every other route's code loads later, on demand, instead of all of it shipping upfront. Bundling the entire application into one file forces every user to download code for routes they may never even visit before the page can become interactive. This defer-until-needed behavior is exactly why code splitting is standard practice for large single-page applications.
3 / 5
In a code review, a dev notices a large single-page application ships every route's code in one single bundle loaded upfront, with no per-route chunking at all, instead of splitting the bundle so each route's code loads only when a user actually navigates there. What does this represent?
This is a missed code-splitting opportunity, since splitting the bundle per route would defer loading each route's code until it's actually needed instead of shipping every route's code in one upfront bundle. A cache eviction policy is an unrelated concept about discarded cache entries. This single-upfront-bundle pattern is exactly the kind of slow initial load a reviewer flags once the application has many rarely visited routes.
4 / 5
An incident report shows a large single-page application's initial load time grew unacceptably slow as the codebase expanded, because every route's code shipped in one single bundle loaded upfront with no per-route chunking at all. What practice would prevent this?
Applying code splitting per route defers loading each route's code until a user actually navigates there instead of shipping all of it in one upfront bundle. Continuing to ship every route's code in one single upfront bundle regardless of how slow the initial load time grows as the codebase expands is exactly what caused the slowdown described in this incident. This per-route-chunking approach is the standard fix once initial load time is confirmed to grow with an expanding codebase.
5 / 5
During a PR review, a teammate asks why the team applies code splitting per route instead of simply minifying and compressing the single bundle harder to shrink its download size. What is the reasoning?
Code splitting reduces how much code downloads on any given page load by deferring routes the user hasn't visited yet, while minifying and compressing harder shrinks the size of the exact same amount of code but still ships every route's code upfront regardless of whether it's ever used on that visit. This is exactly why code splitting and minification are complementary techniques, with code splitting addressing how much code ships and minification addressing how large that code is.