Five mistakes teams make with JavaScript bundle size

The advice here is unglamorous, which is probably why it gets skipped. These are the ones we run into repeatedly when we audit JavaScript bundle size.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to watch for

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Every kilobyte of JavaScript costs more than a kilobyte of image
• Most sites ship libraries for features they barely use
• Never checking whether the fix actually worked

Measure the bundle before optimising anything else. That sounds obvious written down. It is still the thing most often skipped. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Turning this into a decision

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about JavaScript bundle size before you move on:

• Someone can say what the current setup is without going to look
• Measure the bundle before optimising anything else — 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.