Open any React perf thread and someone will suggest aggressive manual chunking in vite.config. Split vendor. Split lodash. Split every route. The treemap looks healthier. Lighthouse barely moves. Sometimes users pay for it with extra round trips.
What chunking is actually for
Code splitting helps when users don't need the code on first paint. Lazy-loaded routes, heavy editors loaded on demand, chart libraries that only show up on one page. Those are real wins. Splitting react-dom into its own chunk because it's big? The browser still needs it immediately.
- First visit: fewer bytes and less parse time on the critical path.
- Repeat visit: vendor chunks that change rarely and cache well.
When manual chunks backfire
Over-splitting creates tiny chunks that block each other, HTTP/2 overhead adds up, and one dependency bump can bust half your vendor tree. You also burn hours tuning rollup output instead of fixing the slow component.
// Often unnecessary early on
manualChunks(id) {
if (id.includes("node_modules")) {
if (id.includes("react")) return "react-vendor";
if (id.includes("lodash")) return "lodash-vendor";
return "vendor";
}
}Vite and Rollup already produce reasonable splits. Reach for manualChunks only after you've measured a specific problem.
Things that usually matter more
- Drop unused dependencies and duplicate date/icon libraries.
- Lazy-load routes and heavy modals with React.lazy + Suspense.
- Fix re-render storms before touching the bundler.
- Serve images in modern formats with explicit width/height.
- Move data fetching server-side where you can (RSC, loaders).
- Audit third-party scripts. Analytics often cost more than your app bundle.
Measure first
Use Lighthouse, Web Vitals in the field, and the Performance panel. If LCP is slow because of a 2MB hero image, chunking react-router won't help. If TBT spikes from a mount effect that maps 10k rows, virtualize the list first.
Treat Vite chunking as a fix for a proven bottleneck. Wait until you have numbers.