Performance is a budget, not a phase
Sites are fast at launch and slow a year later for one reason: nothing stopped them getting slower.
Nearly every site is fast on the day it launches. Someone ran Lighthouse, fixed what it complained about, and shipped. Twelve months later the same site takes six seconds on a mid-range Android, and no single change is to blame — it is forty changes, none of which was individually unreasonable.
The fix is not a better optimisation pass at the end. It is a number the build refuses to cross. We set a JavaScript budget per route and Core Web Vitals thresholds on day one, and wire them into CI. A pull request that pushes a route past its budget does not merge.
This changes the conversation from aesthetic to factual. Nobody has to argue that a particular library is too heavy; the build says so, with a number, before the code is reviewed. And because it fires on the pull request rather than in a quarterly audit, the person who added the weight is the person who removes it, while they still remember why it was there.
It also forces the useful question early: does this feature need to run on the client at all? Most of what makes a marketing site slow is JavaScript that exists to do something the server could have done before the page was sent.
The budget is the deliverable, not the score. A screenshot of a good Lighthouse run proves what one page did on one day. A budget in CI is what keeps it true.
Written by the Valentir team. If you want to argue with any of it, that is what hello@valentir.in is for.