Code Splitting & Route-Based Lazy Loading

The plain-language idea

A single bundle means a single download: every route, every rarely-used feature, every heavy dependency ships to every visitor before the first page can even become interactive, regardless of which page they actually landed on. Code splitting breaks that single bundle into multiple chunks that load on demand, using dynamic import() instead of a static import at the top of the file:

• Route-based splitting — each route's code loads only when that route is actually visited. A visitor who only ever looks at the homepage never downloads the settings page's JavaScript.
• Component-level splitting — a specific heavy, rarely-used component (a rich-text editor, a charting library, a PDF viewer) loads only when it's actually rendered, not as part of the initial bundle every visitor pays for regardless of whether they ever trigger it.

Both reduce the amount of JavaScript that has to be downloaded, parsed, compiled, and executed before the page is interactive on first load — the same JS-cost problem the bundling/tree-shaking lesson addresses from the "remove code nobody imports" angle; this is the complementary "defer code that IS used, just not yet" angle.

See it in a real thing: a route and a heavy component, both deferred

// Route-based: this route's whole subtree loads only when visited
const SettingsPage = lazy(() => import("./routes/SettingsPage"));

// Component-level: only loads once the user actually opens the editor
function DocumentEditor() {
  const [showRichText, setShowRichText] = useState(false);
  const RichTextEditor = lazy(() => import("./RichTextEditor"));

  return (
    <div>
      <button onClick={() => setShowRichText(true)}>Edit</button>
      {showRichText && (
        <Suspense fallback={<EditorSkeleton />}>
          <RichTextEditor />
        </Suspense>
      )}
    </div>
  );
}

Neither SettingsPage nor RichTextEditor's code is in the initial bundle. The browser only requests them, as separate chunks, the moment they're actually needed — a visitor who never opens the editor never pays for its JavaScript at all.

What people usually miss

Watch out

• Code splitting is not tree shaking. Tree shaking removes code nothing ever uses; code splitting defers code that IS used, just not on the very first screen, into a chunk fetched later. A codebase can need both, and fixing one doesn't fix the other.
• Splitting a component that's actually needed for the initial view can hurt, not help, performance. If RichTextEditor above were rendered immediately instead of behind a user action, splitting it would just add a second network round-trip in the critical path for something the browser needed right away.
• Too many tiny chunks has a real cost. Each chunk is a separate request; splitting so finely that a single interaction triggers a cascade of small fetches can add latency that a single, slightly larger bundle wouldn't have had.
• Splitting decisions should be based on what's actually used and when, not guesswork. A bundle analyzer showing what's genuinely large and rarely triggered is the real input to this decision, the same measurement instinct as the bundle-budget material in this track.
• A Suspense fallback for a lazily-loaded chunk is part of the user experience, not an afterthought — a component that pops in abruptly, or a blank gap with no fallback, is a rough edge users notice even when the underlying performance win is real.

Why this matters in interviews

"The initial bundle is huge and most users never touch half the app — how would you fix that?" is a real, common question, and naming route-based and component-level splitting as distinct techniques, plus being honest about the granularity tradeoff, is what separates a real answer from "just add lazy loading everywhere."