JavaScript bundle size: the questions we get asked most

This is cheap to get right at the start and expensive to retrofit. The questions about JavaScript bundle size that come up most often on our calls.

The question is rarely whether something can be built, but what it costs to keep running afterwards. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

Every kilobyte of JavaScript costs more than a kilobyte of image. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Measure the bundle before optimising anything else. That sounds obvious written down. It is still the thing most often skipped. 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

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
• Most sites ship libraries for features they barely use — 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.