How to get code splitting right
It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The short answer to code splitting is that it is mostly a sequence of small decisions, not one big one.
Performance work is mostly subtraction, which makes it unpopular and effective. Assume whoever inherits this will have half your context and none of your patience.
Why this earns attention
Ship the code for this page, not for every page. None of that requires a large budget, only a decision and someone to own it. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- Route-level splitting is the easiest win
- Measure first, because splitting adds requests
- Write down the decision so the next person does not re-litigate it
Measure first, because splitting adds requests. Where this goes wrong is almost never a lack of knowledge. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
A reasonable first step
How to tell if yours is fine
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
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.