Code splitting: route-level, component-level, vendor splitting

A dashboard app ships 900 KB of JS to every page because all routes share one bundle. The homepage needs React, a chart library, a date picker, and the admin panel — even though the homepage never shows a chart, uses the admin panel, or renders the date picker. Three routes of unneeded code travel to the user on every visit to every page.

Route-level splitting

The most impactful change. Each route gets its own JavaScript chunk; navigating to /settings does not download /editor’s bundle. Every modern bundler supports this out of the box.

• Webpack — splitChunks configuration, or React Router 6 with lazy().
• Vite — automatic per-route splitting when using a router plugin.
• Next.js — automatic per-page chunks in both Pages and App Router. Every file in /pages or /(routes) is a separate chunk automatically.
• Remix — route modules are automatically code-split; parallel data loading is built-in.

The senior pattern: every route has its own chunk. If the bundle analyzer shows that 40% of the homepage bundle is from /admin routes, that is route splitting not working.

Component-level splitting

Components that are not on the critical path — modals, sidebars, drawers, admin tools, complex charts — should load only when they are needed. The primitive is dynamic import().

// React
const DatePicker = React.lazy(() => import('./DatePicker'));
// Render only inside a <Suspense> boundary

// Vue
const DatePicker = defineAsyncComponent(() => import('./DatePicker.vue'));

The rule of thumb: any component over 30 KB that is not rendered on first paint should be lazy-loaded. Common candidates: rich text editors, data visualisation libraries, map components, video players, admin panels.

A lazy-loaded component defers its download until the first render. When the user triggers it (opens a modal, navigates to a sub-route), the chunk downloads and parses on the spot. To avoid the visible delay on that first interaction, prefetch the chunk when the user hovers or when the trigger is nearby:

<link rel="prefetch" href="/chunk-datepicker.js" />

Or use React.lazy with import(/* webpackPrefetch: true */ './DatePicker').

Vendor splitting

Third-party libraries (React, React DOM, charting libraries, utility packages) change infrequently compared to your own application code. If they are bundled with your app code, every new deploy invalidates the user’s cached copy of both — the user re-downloads React even though React did not change.

Vendor splitting puts third-party libraries in a separate chunk with its own content hash. The user caches vendor.abc123.js indefinitely. A deploy that only changes your app code invalidates app.def456.js but the vendor chunk stays cached. Second visits after a deploy download only the small changed chunk.

How to configure: Webpack’s splitChunks.cacheGroups, Vite’s manualChunks, Next.js’s automatic framework chunk (framework-*.js in _next/static/chunks/).

The critical path boundary

Not all lazy loading is free. Deferring a component means the first time the user opens it, the chunk downloads and parses in the foreground. This improves LCP (smaller initial bundle) but can hurt INP for that specific interaction.

The rule: keep on the critical path anything the user sees within the first 2-3 seconds of a page load. Defer everything else. If a component is below the fold, behind a click, or on a route the user visits second, it belongs in a lazy chunk.