A speed score after launch is a report card. A budget agreed before design is a constraint you can actually build to.
Most teams meet their site's speed for the first time after launch, as a score in a testing tool. By then the heavy hero video, the third chat widget and the five font weights are already designed, approved and live. Fixing it means undoing decisions people liked.
Agree the numbers up front
Google's Core Web Vitals give you three plain targets to agree before anything is designed. Its published "good" thresholds are:
- Largest Contentful Paint (how fast the main content shows): 2.5 seconds or less
- Interaction to Next Paint (how fast the page responds to a tap): 200 milliseconds or less
- Cumulative Layout Shift (how much things jump around while loading): 0.1 or less
Measure on real phones
Test on a mid-range Android phone over a slower connection, not on the office laptop on fiber. That is closer to how a large share of your visitors arrive, and it is where the budget actually gets spent.
Spend it deliberately
Every feature costs something. A budget turns "can we add a background video?" into "what do we drop to afford it?", which is a far better conversation to have in a design review than after launch. The usual overspends are oversized images, third-party scripts, many font weights and images or embeds that load without reserved space.
Keep it in the pipeline
Run the check on every release, so a change that breaks the budget is caught before it ships rather than discovered months later.
