Who pays for your bundle
The scene repeats with almost comic regularity. Someone opens the build report, points out that the bundle crossed some threshold, and proposes a week of work to cut three hundred kilobytes. The room agrees it matters. Nobody argues. And the ticket goes into the backlog, to a place tickets do not come back from.
It took me a long time to understand that the problem was not the room's priorities. It was the unit I kept bringing into the room.
A kilobyte is nobody's problem. It is a measurement without an owner. When you say "the bundle is 646 KB", the person across the table has to translate bytes into consequence on their own, and they will not do it. Not because they are careless, but because that translation is your job, not theirs.
What "we need to optimise the bundle" actually means
When an engineer says that sentence, they are almost never asking for an optimisation. They are saying something else, usually without the words: people are trying to use this and failing, and I cannot prove who they are.
That version is much harder to ignore. It is also much harder to defend, because it requires knowing who that person is. And this is where most performance conversations die — in the fact that we measure the wrong person.
The median mobile page ships 2,164 KB today. The 90th percentile ships 8,337 KB. Nearly four times the bytes for the same product, depending on where you look. The median is comfortable. The 90th percentile is where the user you never see lives, because they close the tab before becoming a row in your funnel.
Measuring the average is a polite way of measuring yourself.
Three advantages you have and your user does not
Every time you open your own product, you do it with three accumulated privileges.
- The network. Office wifi or home fibre, low latency, nothing competing for it.
- The device. Probably the best phone you have ever owned, or worse, a desktop.
- The cache. You have opened this page a hundred times. Almost nothing downloads again.
None of the three exist on a first visit from someone who arrived through a link. And two of them are invisible in your own monitoring, because your monitoring also runs from well-connected places.
The gap has numbers behind it. The median mobile home page grew from 845 KB in July 2015 to 2,559 KB in July 2025, a 202.8% increase over the decade. No meeting approved that. Nobody wrote a document arguing the page should triple. It accumulated one dependency at a time, each one defensible on its own.
That detail changes the conversation. "The site feels slow" is an opinion. "Our signup ships 646 KB of JavaScript before the first field paints, and the slowest tenth of our sessions take four times the median page weight" is a statement somebody has to answer.
The cost is not the download
This part tends to get explained badly, including by me for a good while.
The 646 KB of JavaScript a median mobile page ships today is not only a transfer. It is code the phone has to download, decompress, parse and execute before it can draw the interface. On a bad connection the download hurts. On a three or four-year-old phone processor, execution hurts alongside it, and that half does not improve when the network does.
Which is why "but faster networks are coming" never resolves the argument. More bandwidth fixes transport. It does not fix the bill for parsing and running code on a modest device.
It is also why shipping less is structurally different from shipping the same thing faster. A CDN moves your bytes closer. It does not make them fewer.
The criteria I use now
I changed how I bring the subject to the table, and the approval rate changed with it.
First: I swap the unit before the meeting starts. I do not talk in kilobytes. I talk about which screen, for which kind of user, on which network condition. "Signup does not open on an old phone on 4G" is a sentence with an owner and a deadline. "Cut 300 KB" has neither.
Second: I measure the 90th percentile, not the average. If your monitoring only shows averages, it is configured to reassure you. The number that matters describes the worst quartile, because that is the experience costing you people.
Third: I bring a person, not a number. A recorded session, a support thread, a video of the flow running on a throttled connection. Thirty seconds of white screen on video convinces better than any chart, because it is uncomfortable to sit through.
And fourth, the one that is least pleasant to admit: if I cannot name who pays, maybe nobody is paying. Which brings me to the honest part.
When the opposite is the right answer
Not every slowness deserves to be fixed, and treating performance as an absolute value is its own way of being wrong.
If the product is an internal tool used by forty people who all sit in the same office on the same company-issued laptops, the 90th percentile and the median are effectively the same number. There is no hidden user in the tail. Cutting the bundle there optimises something with no cost attached, and the time spent goes missing from a feature somebody actually asked for.
The same goes for a dashboard a team leaves open all day. The load cost is paid once, in the morning, and amortised across eight hours of use. Twenty seconds of initial load in a product like that is annoying. It is not expensive.
And there is the case where the slowness is real but is not the bottleneck. A site that loads slowly and converts badly may be converting badly because it does not state the price, does not state the lead time, and does not say who it has worked with. None of those three is fixed by code splitting. Optimise first and you will win half a second and no sales, having spent your political capital on the wrong subject.
The question that separates the cases is always the same. Is there someone, on a worse connection and a worse device than mine, trying to do a specific thing in this product and giving up? If you can answer who, performance has become product work. If you cannot, it is still technical vanity, however true the number happens to be.
Worth asking: in your monitoring, can you actually see the 90th percentile — or only the average that keeps you calm?