Why Fast Apps Slowly Become Slow Apps: How a Performance Budget Protects Speed at Scale
The suitcase at the check-in counter
At an airport check-in counter, your bag has a weight limit, often around 23 kg. Nobody packs an overweight bag on purpose. You add a pair of shoes. Then a gift for your cousin. Then “just one more small thing.” At home, the bag feels fine. At the counter, the scale does not care about your reasons. If you are over the limit, something has to come out.
Software has the same problem, with one big difference: most teams have no scale at the counter.
How fast apps get slow
On my previous post we learned to measure before and we also looked at the four delays behind every slow page. Today is about a different question: once you have made an app fast, how do you keep it fast?
Here is how it usually goes wrong.
In January the page is quick. In February the marketing team adds a tracking script. In March a chat widget goes in. In April a designer swaps a light banner for a beautiful, heavy one. In May someone adds a library to format dates, and it brings fifty friends. Every change is small, reasonable and approved by someone. By June the page is twice as heavy, and nobody can point to the day it happened.
Engineers call this performance regression by a thousand cuts. No single change is the villain, so no single person feels responsible.
What a performance budget is
A performance budget is a written limit that every change must fit inside. It works like the baggage limit: simple, public, and checked by something that does not negotiate.
There are three kinds, and good teams use all three.
1. Quantity budgets: These limit what you ship. For example, the JavaScript needed for the first screen must stay under a set number of kilobytes, total image weight under a set limit, and the number of requests under a set count.
2. Timing budgets: These limit what users feel. For example, LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and time to first byte at 0.8 seconds or less, all measured on real users at the 75th percentile, like Google does.
3. Score budgets: A minimum Lighthouse score. I treat this one as a smoke alarm, not the goal. A score can be gamed, and a lab score is not the same as real user experience.
Get Rufus Kehinde’s stories in your inbox
Join Medium for free to get updates from this writer.
How to set the numbers
Do not copy a number from a blog post. A limit you cannot defend will be ignored the first time it is inconvenient.
Measure your current baseline first.
Look at the devices and networks your real users have. A budget that works on a flagship phone can fail on a mid range phone with a weak signal.
Compare against your closest competitors. If their product loads in two seconds, a four second page is a business problem, not a technical detail.
Start slightly better than today’s baseline, then tighten it over time.
To make it concrete, here is the shape of a budget. These are examples only, and yours must come from your own measurements. First screen JavaScript at a set compressed size cap. Total page weight under a set limit. LCP at the 75th percentile at 2.5 seconds or less. Time to first byte at the 75th percentile at 0.8 seconds or less. A maximum number of third party scripts.
How to enforce it, because a budget nobody enforces is a wish
The check-in counter in your pipeline is your CI system, the automated checks that run on every code change.
A tool such as size-limit, bundlewatch or Lighthouse CI runs on every pull request. If the new code pushes a bundle past its limit, the build fails and the developer sees exactly how much they went over.
Webpack and similar bundlers have built in performance hints that warn when assets grow too large.
The rule that makes it fair: to add weight, remove weight. If a team truly needs to go over, they defend the exception in writing, and someone with authority approves it.
Lab checks are not enough
CI tests run on a fixed, synthetic setup, so they catch regressions before release. They cannot catch what only happens in the wild: a slow region, a cheap phone, a third party script that changed its behavior without telling you.
So you also need field monitoring. Real user monitoring tools, or the web-vitals library sending data to your analytics, track what actual visitors experience. Set alerts on the 75th percentile, for example when LCP gets worse and stays worse for a sustained period. For big releases, use a canary rollout: send the new version to a small slice of users first, compare their numbers against the old version, and only then go to everyone.
The scale lens: why this matters more at millions of users
Small regressions become large bills at scale. Say a feature adds 50 KB to every page load. Across 1 million visits, that is about 50 GB of extra transfer. Now imagine ten teams each adding 30 KB. That is 300 KB of new weight on a page, and per million visits, about 300 GB, before anyone noticed.
That cost lands in three places at once: the infrastructure bill, the user’s data plan, and the user’s patience.
Large organizations also solve the people problem, not just the tooling problem
1. Ownership: A named team owns each budget, not “everyone,” because “everyone” means no one.
2. Visibility. The budget status lives on a dashboard that product managers and executives can read, so speed is a business metric, not a developer hobby.
3. A clear exception process: Rules with no exceptions get bypassed. Rules with a visible exception process get respected.
The tradeoffs
1. Budgets slow feature teams down. That is intentional, but it needs leadership support, or the budget gets deleted the first time a deadline gets tight.
2. Bad budgets are worse than none. If a limit is arbitrary, people will game it. Tie each number to a user outcome you can explain.
3. Lab budgets can give false confidence. Always pair them with real user data.
4. Third party scripts are the hardest part, because you do not control their code. Treat each one as a purchase: it needs a justification and an owner.
Tools to start with
1. Lighthouse CI, to run performance checks automatically on every change
2. size-limit and bundlewatch, to fail builds when bundles grow
3. webpack performance hints (or your bundler’s equivalent)
4. The web-vitals library, to collect real user metrics
5. SpeedCurve or a similar monitoring service, for trends and alerts
