Code splitting, explained without the jargon

There is no clever trick in this one, just a handful of decisions worth making deliberately. Here is code splitting without the vocabulary that usually surrounds it.

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. It rarely shows up as a line item, which is exactly why it slips.

The short version

Ship the code for this page, not for every page. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. None of that requires a large budget, only a decision and someone to own it.

Route-level splitting is the easiest win. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Making it stick

Measure first, because splitting adds requests. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What this looks like day to day

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
• Ship the code for this page, not for every page — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.