Bundle splitting is about deferring code until needed without creating new problems (waterfalls, too many tiny requests, cache invalidation). The strategy depends on the framework, but the principles are universal.

Where to split

1. Per route. Every page is its own chunk. Frameworks handle this:

• Next.js: automatic for App Router and Pages Router.
• React Router: createBrowserRouter with lazy per route.
• Remix: per-route automatically.
• Vite + react-router-dom: manual via React.lazy.

2. Per heavy widget. Modals, drawers, rich-text editors, chart libraries, code editors, file uploaders — anything loaded on interaction.

const Editor = lazy(() => import('./Editor'));
{editing && <Suspense fallback={<Spinner />}><Editor /></Suspense>}

3. Per locale. Don't ship 30 languages of translations to every user.

const messages = await import(`./locales/${locale}.json`);

4. Per feature flag / experiment. Code behind a flag the user can't see shouldn't ship to them.

5. Per device class. Mobile-only or desktop-only features split out.

Vendor chunking

Default of "put all node_modules in one big vendor chunk" is bad: any dep update invalidates the whole vendor cache for users. Better:

• Group by stability: separate React core (rarely changes) from utility libs (changes more often).
• Group by usage: deps used only on certain routes belong in those route chunks.
• Split large deps individually: chart.js, mapbox-gl, pdfjs get their own chunks.

Webpack splitChunks.cacheGroups config or Next's automatic chunking handles this.

Avoiding waterfalls

A chunk that depends on another chunk creates a sequence: load A → discover need for B → load B. Total time = A latency + B latency.

Fix:

• Co-locate dependencies so they ship together.
• Prefetch B when A loads, so by the time A wants B it's already cached.
• Don't dynamic-import inside lazy chunks unnecessarily.

Preloading next-likely chunks

<Link href="/admin" prefetch>Admin</Link>   // Next.js prefetches on viewport

Or on hover:

<a
  href="/admin"
  onMouseEnter={() => import('./admin/page')}
>
  Admin
</a>

Idle-time prefetch via requestIdleCallback for less-certain navigations.

Chunk size sweet spot

• Too small (< 30KB): HTTP overhead dominates, too many requests.
• Too large (> 500KB): defeats the splitting purpose.
• Sweet spot: 50–200KB compressed per chunk.

For HTTP/2/3 with multiplexing, slightly more smaller chunks is fine; for HTTP/1, fewer larger chunks.

Caching with hashed filenames

main.abc123.js
admin.def456.js

Each chunk has a content hash. Long max-age + immutable on the URL. New content → new hash → new URL → users get the new code without invalidating the old.

Measuring

• Bundle analyzer (webpack-bundle-analyzer, vite-bundle-visualizer, next-bundle-analyzer): visualize the chunk graph.
• Coverage tab (Chrome DevTools): see what JS was actually executed on a page.
• Network panel: identify waterfalls (sequential blocking requests).
• Lighthouse: "Reduce unused JavaScript," "Avoid chaining critical requests."

Set a CI budget

// size-limit config
[
  { name: 'main', path: 'dist/main.*.js', limit: '150 KB' },
  { name: 'vendor', path: 'dist/vendor.*.js', limit: '200 KB' },
]

PR fails if a chunk regresses. Without enforcement, splits get undone by accidental imports over time.

Common pitfalls

• Splitting tiny components: HTTP overhead exceeds the payload — keep them bundled.
• Splitting on the critical path: visible loading spinner replaces invisible parsing — bad UX.
• Mega vendor chunk: any dep update invalidates the whole thing.
• Waterfalls: lazy-route → lazy-component → lazy-data. Each step adds latency.
• Forgetting Suspense: React.lazy without Suspense throws.
• Not prefetching: every nav waits for a network round-trip even when the next route is predictable.

Decision flow

1. Per route: should be automatic. Verify.
2. Heavy widgets: split if > 30KB and not always rendered.
3. Vendor: split by stability/usage, not just node_modules.
4. Prefetch: hover + viewport for predictable navs.
5. Budget: set in CI before things regress.

Modern context

• React Server Components (RSC) skip the JS entirely for server-only code — even better than splitting.
• 'use client' boundaries in Next 13+ define exactly what JS ships.
• Module Federation for microfrontends: chunks are shared across deploys.

Bundle splitting is less critical than it was when RSC didn't exist, but for the JS that does ship to the client, the rules above still hold.