Every team that ships a performance project watches the gains evaporate over the following year, one marketing tag, one carousel, one dependency at a time. Speed is not a project deliverable; it is a budget, and budgets only survive when someone defends them continuously.
Set budgets people can see
Pick concrete ceilings, JavaScript under a fixed size on key pages, LCP under 2.5 seconds on a mid-range phone, no third-party tag without a named owner, and enforce them in CI so a pull request that blows the budget fails visibly. A budget that only exists in a wiki is a suggestion; a budget in the build pipeline is policy.
Measure what users experience
- Field data (real user monitoring, CrUX) tells you what actually happens on customers' devices and networks; lab tests only tell you what is possible.
- Test on hardware that resembles your audience's median phone, not a developer laptop.
- Watch percentiles, not averages: the 75th and 95th percentile users are where revenue quietly leaks.
The recurring offenders
Most regressions come from a familiar cast: third-party scripts nobody audited, images shipped at capture resolution, JavaScript bundles that grow because importing is easier than asking, and web fonts loaded four weights deep. A quarterly audit of tags and dependencies, with an actual uninstall step, recovers more milliseconds than most clever engineering.
Tie speed to money, or lose the argument
Performance work competes with features for time, and it wins only when framed in business terms. Correlate load time with conversion and bounce in your own analytics, then report speed in revenue language. "The checkout got 400 milliseconds slower and conversion dropped half a point" gets prioritized; "Lighthouse went orange" does not.