Performance
Code splitting
Code splitting is sending the JavaScript for the current screen instead of the whole app. Bundlers cut the code into chunks that load on route change, interaction, or visibility.
How it is measured
Look at the bundle analyzer and the Network panel. Count the kilobytes of JavaScript downloaded on first load, and the share of it that actually executes, using the Coverage tab in DevTools. Unused bytes are the target.
Dynamic `import()` is the usual mechanism. Frameworks split by route automatically, but heavy libraries inside one route still end up in the same chunk unless you split them on purpose.
Worked example
A SaaS settings page loads a 620 KB main bundle that includes a charting library used only on the reports tab. Moving the chart to a dynamic import cuts the first bundle to 380 KB. On a mid-range phone, Total Blocking Time falls from 780 ms to 410 ms.
The reports tab now pays a 140 ms delay the first time it opens. A `<link rel="prefetch">` on hover hides most of it.
How it differs
Code splitting cuts a bundle into pieces that load when needed. Tree shaking removes code that nothing imports. Splitting moves code to later. Tree shaking deletes it. Hydration cost depends on how much of the split code must run on first load.
Common errors
Splitting so finely that a screen needs fifteen requests. Splitting without prefetching, so the first click stalls. Leaving a large vendor chunk that contains everything. Forgetting that duplicated dependencies across chunks inflate the total. Measuring only transfer size and ignoring parse and execute time.
In practice
Run the analyzer on your production build and find the three largest modules. Move anything not needed for the first view behind a dynamic import. Prefetch the next likely chunk on idle or hover, and recheck Total Blocking Time and INP after.