Most performance work happens at the end of a project, when there is no budget left to do it well. By then the bundle is huge, the third-party scripts are entangled, and someone has already loaded fourteen Google Fonts. The cheapest performance improvement on any project is the one made before code is written.
The budget, in a single page.
- LCP: < 2.5s on a mid-tier mobile phone over 4G. Target < 1.5s for product and category pages.
- INP: < 200ms on every interactive element on every page.
- CLS: < 0.1. Hero images, web fonts and third-party embeds are all responsible for hitting this number.
- TTFB: < 600ms on cached pages. Anything above this points at hosting or back-end work needed before front-end optimisation makes sense.
- JS bundle (initial): < 100KB gzipped on first load. Code-split everything else.
- CSS: < 30KB gzipped on first load. Critical CSS inlined; rest deferred.
- Images: AVIF / WebP with JPG fallback. Every responsive image declares srcset and sizes correctly.
- Fonts: Maximum two families, three weights each. font-display: swap, preloaded.
- Third-party scripts: Maximum five on first load. Anything else loads on user interaction or idle.
Why these numbers.
The Core Web Vitals thresholds are Google's, not ours. The bundle-size targets come from observing what survives the next two years of feature additions; if you start at 100KB on day one, you finish at 280KB on day 800, which is just about livable. Start at 300KB on day one and you finish at unrecoverable.
The font and third-party-script targets are the ones developers ignore. A second analytics tool, a chat widget, a heatmap, two retargeting pixels, a consent banner and a personalisation tool will single-handedly tank your CWVs no matter how well the rest of the build is done. Set the budget, and make adding the seventh script require an explicit conversation.
How to enforce it.
The budget belongs in CI. Lighthouse CI runs on every pull request and fails the build if the targets aren't met. size-limit on the JS bundle. image-min on every image in the repo. None of this is exotic; the value is in actually running it from commit one, not from "we'll add CI later."
A performance budget on a slide deck has zero effect on the final build. A performance budget in CI fails 30+ pull requests in the first month and changes how the team thinks about every feature after that.
What this is not.
This is not a guarantee. Real-world performance is dominated by what happens on user devices and networks, not in your test harness. The budget is a floor — if the synthetic test passes, the real-user numbers might still be marginal. The point of the budget is to make sure you never start a feature ten times slower than you should.
If you want the one-page version of this document — print-ready, brand-able, hand-able to a developer on day one of a new project — drop us a line. We send it for free, no funnel.