Code splitting for small teams

This is cheap to get right at the start and expensive to retrofit. Most advice about code splitting assumes a team that does not exist at your size. Here is the version that does not.

Performance work is mostly subtraction, which makes it unpopular and effective. Budget a little time for it every quarter and it never becomes a project of its own.

What to keep

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. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. It is worth being explicit about, because assumptions differ quietly.

How we handle it

Measure first, because splitting adds requests. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

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

Pick the one that would hurt most if it failed, and start there.