Set a performance budget before you design the website

Most slow websites were fast in the first demo. They got slow one reasonable decision at a time: a video header, a third tracking script, a font with six weights, a carousel plugin. A performance budget is the agreement that stops those decisions from accumulating.

What a budget contains

We set targets for the three Core Web Vitals, plus limits that teams can actually check during the build:

• Largest Contentful Paint under 2.0 seconds on a mid-range phone over a 4G connection.
• Interaction to Next Paint under 200 milliseconds.
• Cumulative Layout Shift under 0.1.
• Total JavaScript shipped on the home page under 150 KB compressed, excluding anything that is lazy loaded on interaction.
• No more than two font families and four weights, served from your own domain.
• Every image sized for its container and delivered as WebP or AVIF.

How it changes design

A budget makes trade-offs visible early. If a 3D hero costs 500 KB, that is a conscious choice, and it should be lazy loaded after the first paint and skipped entirely for visitors who prefer reduced motion. If a page needs eight tracking scripts, the budget forces the question of which three matter.

Designers work with real content and real images from the start, so there is no late surprise when the placeholder photography is replaced with ten-megabyte originals.

How to enforce it

1. Put the budget in the project brief and the repository readme.
2. Run Lighthouse in continuous integration and fail the build when a metric crosses the line.
3. Review the budget at every design review, not only at launch.
4. After launch, watch field data in Search Console and PageSpeed Insights monthly, because real users on real devices are the only measurement that counts.

A performance budget does not make a site boring. It makes every expensive element earn its place, which is what good design does anyway.