Is transfer size or parse time the real cost?

Parse and execution, usually. It is main-thread work that scales with device capability, which varies far more than bandwidth and has improved far less.

Can I split too much?

Yes. Very small chunks cost more in overhead and loading states than the code they save, and a split on the critical path turns one fetch into two sequential ones.

Does bundling still help now that connections are reused?

Much less for request count. The remaining argument against many files is discovery ordering; the argument for them is caching, which favours splitting on a site that deploys often.

Glossary

Code splitting

Code splitting breaks an application's JavaScript into separate files loaded on demand, so a visitor downloads and executes only what the page they opened requires. The benefit people expect is transfer size, and the benefit that matters more is parse and execution time: a large bundle costs main-thread work proportional to its size, and that work blocks interaction on exactly the low-end devices where it hurts most.

Why parse cost matters more than transfer

Transfer is bandwidth, which varies widely and has improved steadily.

Parsing and executing JavaScript is processor work on the main thread, which varies by device far more than bandwidth does and has improved far less.

A bundle that transfers in a second on a phone can take several seconds to parse and execute on the same phone.

Which is why removing a script is worth more than compressing it, and why the honest advice is usually to ship less rather than to ship it faster.

It is also why the same bundle behaves acceptably on a development machine and badly in the field.

Where the split lines usually go

By route, so opening one page does not load the code for every other.

By interaction, so a component that appears in a modal loads when the modal is opened rather than on every page.

By dependency, isolating a large library used in one place so it is not in the path everyone pays for.

Vendor code separately from application code, so a dependency update does not invalidate the cached copy of everything else.

That last one is a caching benefit rather than a size benefit, and it is frequently the most valuable split on a site that deploys often.

Where it goes too far

Very small chunks, where the per-request overhead and the loading state cost more than the code saved.

A split on the critical path, which turns one fetch into two sequential ones and delays rendering.

Splitting something used on nearly every page, where the chunk is loaded everywhere and the split only added indirection.

Which is why the useful question is not how many chunks but whether a given chunk is avoided by a meaningful share of visits.

The trade with caching

One large bundle means any change invalidates all of it for every returning visitor.

Several chunks mean a change invalidates only what it touched, which is worth more the more often a site deploys.

This is the argument that survived the shift to multiplexed connections, where the per-request penalty that once favoured bundling largely disappeared.

Fingerprinted filenames are what make it work, since they let each chunk carry the longest possible cache lifetime.

How it is observed

Total JavaScript payload is measured, and the heaviest individual script files are listed.

The number of resources the served markup references is reported as context rather than as a target.

Whether static assets carry fingerprinted names and long cache lifetimes is read from the caching headers.

Which chunks a given route loads on demand is runtime behaviour and is not observable from the served markup alone.

Frequently asked questions

Is transfer size or parse time the real cost?: Parse and execution, usually. It is main-thread work that scales with device capability, which varies far more than bandwidth and has improved far less.
Can I split too much?: Yes. Very small chunks cost more in overhead and loading states than the code they save, and a split on the critical path turns one fetch into two sequential ones.
Does bundling still help now that connections are reused?: Much less for request count. The remaining argument against many files is discovery ordering; the argument for them is caching, which favours splitting on a site that deploys often.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website