Getting started with code splitting
There is no clever trick in this one, just a handful of decisions worth making deliberately. A short on-ramp to code splitting for teams who have not touched it before.
Real-world numbers from actual visitors matter more than a score produced on a fast laptop. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What it costs to ignore
Ship the code for this page, not for every page. In practice this is a scheduling problem more than a technical one. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Your first week
- Find out what is already in place
- Route-level splitting is the easiest win
- Change one thing and measure it
Measure first, because splitting adds requests. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.
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
The point is not perfection, it is knowing which of these you have consciously chosen to skip.