A module split moves some JavaScript from the initial bundle to a later request. That can reduce parse and execution work for visitors who never use an optional feature. It also creates a new loading boundary when the feature is opened. A good split follows a user task: the case list should not eagerly parse the image-annotation editor, but clicking 'Annotate' should not leave a blank panel while code downloads. Prefetching after clear intent, a progress state, an error path, and a retry policy keep the new boundary honest.
Make this comfortable
Module Splitting and Interaction Budget
Working case
Only a small share of reviewers annotate inspection photos, yet every case-list visitor downloads the editor package. The list feels slow on modest phones. Move the editor to an on-demand module and keep the list functional without it. When a reviewer opens image 61, show a useful loading state and fetch the module. A failed chunk request must offer retry or a plain-text note alternative; otherwise the optimization has exchanged a slower page for an unusable critical action.
Implementation boundary
async function openPhotoEditor(imageId) {
const openButton = document.querySelector("#open-photo-editor");
openButton.disabled = true;
try {
const { mountEditor } = await import("./photo-editor.js");
await mountEditor({ imageId, container: document.querySelector("#editor-panel") });
} finally { openButton.disabled = false; }
}The split defers the editor module until activation. A production path should catch download and mount errors, display a retry or alternate workflow, and avoid repeated imports caused by rapid clicks. The browser typically caches the loaded module, but a deployed release can remove old chunk names while an old tab remains open; a chunk failure may require a controlled refresh after preserving unsaved work. Keep a small visible placeholder and measure time from activation to usable editor, not only initial bundle size.
Cost and boundaries
The initial route saves transfer, parse, and execution work proportional to the deferred module. The first editor use pays an extra network round trip and evaluation cost. Splitting every small component can create request overhead and complex failure handling; group code by meaningful tasks. Prefetching can hide latency after a hover or route intent, but it consumes bandwidth for people who never open the editor. Compare actual task completion and interaction delay across devices before deciding the boundary is worthwhile.
Failure trace
The initial bundle shrinks, so a lab score improves. On a slow connection, the first annotation click waits several seconds and the panel stays empty. An old tab then requests a chunk deleted by a new deployment and fails permanently. Track the editor-open journey, provide progress and a recovery route, and keep compatible assets during rollout where possible. A smaller file does not by itself prove a better interaction.
Verification
- Compare initial list parse cost before and after the editor split.
- Measure time from activation to usable editor on a cold slow connection.
- Force chunk failure in an old tab and verify recovery preserves context.
Practice drill
Measure initial list load and first editor-open time separately. Repeat on a warm cache, a cold slow connection, and an old tab after deployment. Simulate a rejected module request and verify the reviewer can retry or save a plain note without losing the case context. Remove any prefetch rule that consumes bandwidth without materially improving the first useful editor interaction.
Decision note
Split by optional task, then budget both sides of the boundary: first-page cost and first-use delay. Optimize the workflow, not a bundle-size number alone.
Common Mistakes
- Splitting tiny modules until request overhead dominates.
- Showing no progress while a deferred action loads.
- Dropping old chunks immediately while open tabs still reference them.
Connected lessons
Typed Frontend and Component Platform; TypeScript and Runtime API Boundaries; React Effects and Request Races; Web Components and Shadow Boundaries; Page performance: budget the critical path and reserve layout space; Field and Lab Performance Evidence; Continuous Integration and Release Gates.
Apply and check
Build Project: typed review console and review Web Development: platform and trust contracts quiz.
Further connections
Navigation Prefetch and Private Data Budget.
Further connections
web-tech
web-development