A React app that ships its entire JavaScript bundle to every visitor, regardless of which page or feature they actually use, is one of the most common and most fixable performance mistakes we find in code we inherit from other teams. Code splitting solves this directly, and it’s genuinely simpler to implement well than most teams assume once the underlying idea clicks.
The core problem code splitting solves
By default, a bundler combines your entire application’s JavaScript into one (or a few) large files, all downloaded before your app becomes interactive - including code for admin panels a regular user never sees, checkout flows a browsing-only visitor never reaches, and heavy third-party libraries used by one rarely-visited feature. Every visitor pays the download cost for all of it, whether they use 5% or 100% of the application.
What code splitting actually does
Instead of one large bundle, code splitting breaks your application into smaller chunks that load on demand - a route’s code loads when a user navigates to it, a heavy component’s code loads only when that component is actually about to render. React’s built-in `lazy()` and `Suspense` make this straightforward for component-level splitting; most modern frameworks (Next.js, for instance) handle route-level splitting automatically without extra configuration.
Where to actually apply this for real impact
- Route-level splitting, almost always the highest-impact starting point. Each page or major route becomes its own chunk, so a visitor to your homepage never downloads the code for your admin dashboard or a rarely-visited settings page.
- Heavy, conditionally-rendered components. A rich text editor, a charting library, a complex modal that only renders after a specific user action - these often pull in substantial library weight that shouldn’t be part of the initial bundle every visitor downloads regardless of whether they trigger that feature.
- Below-the-fold or rarely-used features that are present on a page but not immediately needed - a comments section, a secondary tab’s content - can be split and loaded just before they’re needed, rather than blocking initial page interactivity.
Where teams get this wrong
Over-splitting - breaking an application into so many tiny chunks that the overhead of many small network requests outweighs the benefit of smaller individual downloads - is a real, if less common, mistake. The right granularity is usually at meaningful feature or route boundaries, not every individual component split into its own chunk regardless of size. The other common mistake: splitting code but not providing a genuinely good loading state (via Suspense) for the split chunk, so users see a jarring blank flash while a chunk loads instead of a deliberate, smooth loading indicator.
How to actually verify this is working
Bundle analysis tools (webpack-bundle-analyzer or equivalent) show you exactly what’s in your initial bundle versus what’s been successfully split out - this is the concrete way to verify code splitting is actually reducing what a typical visitor downloads, rather than assuming it’s working because you added a few lazy() calls. We run this analysis on every project as a standard check, not an occasional audit.
What we actually recommend
Start with route-level splitting - it’s the lowest-effort, highest-impact change for most applications, and most modern frameworks give it to you close to automatically. Layer in component-level splitting specifically for identified heavy, conditionally-used features, verified with real bundle analysis rather than assumption.
We build performance-conscious React applications with this discipline as standard practice, as part of our React and Next.js development work. Get in touch if your app’s initial load feels heavier than it should for what a typical user actually needs.