JavaScript bundle size: what to get right first

Every audit we run turns up some version of this. If you only fix one thing about JavaScript bundle size this quarter, make it the first item below.

Most development decisions are really maintenance decisions wearing a different hat. Assume whoever inherits this will have half your context and none of your patience.

Start here

Every kilobyte of JavaScript costs more than a kilobyte of image. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.

Then this

Most sites ship libraries for features they barely use. The teams that handle this well are rarely the ones with the biggest budgets. It rarely shows up as a line item, which is exactly why it slips.

Eventually

Measure the bundle before optimising anything else. The teams that handle this well are rarely the ones with the biggest budgets. If two people in the business would answer this differently, that gap is the actual problem.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.