Why code splitting matters more than it looks
Most teams know this matters. Fewer have decided who owns it. Code splitting is easy to treat as a detail, and that is exactly why it is worth a few minutes of attention.
Performance work is mostly subtraction, which makes it unpopular and effective. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
What it costs to ignore
Ship the code for this page, not for every page. The teams that handle this well are rarely the ones with the biggest budgets. Budget a little time for it every quarter and it never becomes a project of its own.
Route-level splitting is the easiest win. Getting it slightly wrong is survivable. Ignoring it entirely is not. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Warning signs
Measure first, because splitting adds requests. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.
The short version
Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about code splitting before you move on:
- Someone can say what the current setup is without going to look
- Measure first, because splitting adds requests — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.