When deciding where to put `import()` split points in an application, what makes a call site a good boundary, and what goes wrong when a team splits too aggressively?

## The thing you are actually trading Lazy loading does not make an application smaller. The same code still ships; sometimes slightly more, because splitting duplicates a little shared plumbing and adds a request. What changes is **when** each byte is paid for, and by which user. That reframing drives every decision. A split point moves cost from "everyone, on first load" to "the subset who take this action, at the moment they take it". It is a win when the subset is small and the moment is forgiving. It is a loss when nearly everyone takes the action, or when the moment is one where the user is already waiting. ## What makes a call site a good boundary Four tests, roughly in order of importance: **Is it big?** Below some threshold the round trip dominates the payload. A module of a few kilobytes is not worth a request; a library measured in hundreds is. **Is it genuinely optional?** If 90% of sessions open the thing, you have deferred work almost everyone needs and added latency to the path that matters. Reserve boundaries for genuinely conditional code: admin-only tools, a rich editor, an export flow, an error-reporting fallback, a locale bundle where only one of many is needed. **Does the boundary cut cleanly?** A good boundary has few shared dependencies with the rest of the app. If the lazy module and the initial payload share most of their dependency tree, you have split the entry point but not the weight. **Can you predict the need?** Boundaries you can warm are far better than boundaries you cannot. `import()` on hover, on focus, on route-adjacent navigation, or during idle time turns a blocking wait into a load that has already fulfilled by click time. Caching the *promise* is what makes this trivial: ```js let editor; const loadEditor = () => (editor ??= import('./editor.js')); button.addEventListener('mouseenter', () => loadEditor().catch(() => {})); button.addEventListener('click', async () => { const { mount } = await loadEditor(); mount(); }); ``` ## The failure modes of over-splitting **Waterfalls.** This is the real damage. If a lazily loaded route module itself lazily imports its panel, and the panel lazily imports its chart, then each request can only start once the previous one has been fetched and evaluated. Three round trips in sequence, on a slow connection, is a visibly broken interaction. The fix is to make the *inner* dependencies static, so the outer boundary pulls its whole subtree in one go, and to keep boundaries shallow — a flat set of split points at route or feature level rather than a tree of them. **Latency where the user is watching.** Deferring work to a click means the user has expressed intent and is now waiting. Deferring to first paint means they were waiting anyway. Splitting the wrong side of that line trades invisible cost for visible cost. **Request overhead multiplying.** Many small units mean many requests, each with its own overhead and each needing to be parsed and evaluated separately. Past a point, the aggregate is slower than one larger unit even though the byte count is similar. **Caching churn.** Each boundary is a separately versioned artefact. Fine-grained splitting means a small change invalidates several units instead of one, and every unit is another thing that can go missing after a deploy while an old page is still open. **Asynchrony leaking upward.** Every `import()` makes its call path asynchronous. Push boundaries deep into the code and a function that used to return a value now returns a promise, its callers become `async`, and error handling has to be threaded through all of it. Boundaries belong at architectural seams — routes, feature entry points — where the code is already asynchronous, not in the middle of a utility. **Rejection surface.** Every boundary is a load that can fail independently. Ten boundaries is ten places needing an error path, or ten ways to get a dead control. ## How to reason about it as a lead Set the default: **static unless argued otherwise**. Static imports are simpler, analysable, and free of the failure modes above. Require a reason for each boundary, and prefer a small number of coarse boundaries — one per route or per major optional feature — over many fine ones. Measure rather than guess. The questions worth answering are: what fraction of sessions actually load each lazy unit, how long does that load take at the 95th percentile, and how much did initial payload actually fall when the boundary was introduced. A boundary that 95% of sessions cross is a boundary that should not exist. One that 3% cross and that removes a large library is doing its job. Budget it. "Initial payload under X, no more than N boundaries on any single interaction path" is a constraint a team can hold, and it prevents the drift where every new feature adds another lazy layer because that is the local habit. Finally, keep the *interaction* honest: pair each boundary with a pending state and a bounded failure path, and warm it wherever intent is observable. A split point that is warmed on hover and falls back gracefully is a genuinely better experience; the same split point with no warming and no error state is a slower, more fragile app that merely scores better on an initial-payload metric.