Code-Splitting and Preloading Strategies
Learn how React treats JavaScript code as a schedulable dependency, and how intentional code-splitting combined with preloading shapes when UI becomes renderable, rather than just how much code is loaded.
As React applications grow, JavaScript delivery becomes a bottleneck, not because the browser can’t execute code fast enough, but because React can’t commit UI until the code for that UI exists. And that bottleneck doesn’t appear as “large bundles” on a dashboard. It shows up as stalls people can feel: you navigate, and the next screen can’t commit Yet; you open a panel, and React hits missing code, so a Suspense fallback appears; a modal should feel instant, but the UI hesitates; interactions register, but everything feels delayed because the next renderable subtree isn’t ready.
From React’s perspective, the real cost of big JavaScript isn’t size, it’s render readiness. UI can’t be committed until the code that defines it has been downloaded, parsed, and evaluated. That’s why code splitting isn’t just a bundling trick. It’s a render scheduling tool: it lets you decide what must be present for the first commit, what can wait for later commits, and what should start loading early based on user intent.
Preloading complements splitting by shifting when the missing code starts loading. If a chunk is requested only when React tries to render it, suspension is likely. If the request starts earlier, on navigation, hover, or focus, React often reaches the subtree before the code is even in flight (or cached), shrinking or eliminating fallback time.
Used well, splitting and preloading enable a streaming-first experience: the shell commits immediately, primary UI appears as soon as it becomes renderable, and optional features upgrade later without destabilizing what’s already on screen. Used poorly, they create more fallbacks and push interactivity out. The difference comes down to feature seams, boundary placement, and intent-driven loading.
How splitting and preloading work
Code splitting is best understood as deferring render work by deferring code availability. When a component is split into a separate chunk, React may reach it during render and find that its module hasn’t loaded yet. In that case, the subtree can’t be completed. “Code is treated like data. If it isn’t ready during render, React suspends the subtree.”
Preloading complements code splitting by controlling when that dependency starts ...