A short guide to JavaScript bundle size

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Everything we would tell a client about JavaScript bundle size in the time it takes to drink a coffee.

Most development decisions are really maintenance decisions wearing a different hat. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What it costs to ignore

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. If two people in the business would answer this differently, that gap is the actual problem.

How we handle it

Most sites ship libraries for features they barely use. Small and consistent beats large and occasional here. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to watch for

Measure the bundle before optimising anything else. In practice this is a scheduling problem more than a technical one. If two people in the business would answer this differently, that gap is the actual problem.

In practice

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
• 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

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