A performance budget that survives the deadline

Everyone agrees the site should be fast. Then a marketing tag goes in on a Thursday, nobody measures, and three months later you are in a meeting about why the site is slow.

The fix is not discipline. It is making the budget something the pipeline enforces, so no individual has to be the one who says no.

Pick three numbers, not fifteen

A budget nobody remembers is not a budget. Three numbers:

• LCP under 2.0 s on a simulated mid-range Android over 4G.
• Total JavaScript under 200 KB compressed, on the heaviest route.
• CLS under 0.05.

That is it. If those three hold, the rest is usually fine.

Measure the route, not the homepage

The homepage is the page everyone optimises and almost nobody lands on. Run the check against your three highest-traffic routes from analytics. For the storefront I rebuilt last year, that was a category page, a product page and the cart — the homepage was fourth.

Make it a pull request check

- name: Lighthouse CI
  run: |
    npx @lhci/cli autorun \
      --collect.url=https://staging.example.com/products \
      --assert.assertions.largest-contentful-paint=error:2000

A failing check is a conversation at review time, which is cheap. The same conversation three months later costs a sprint.

Budget the third parties separately

First-party code rarely causes the regression. Tags do. Keep a list of every third-party script with its owner and its measured cost, and review it quarterly. Half of them will turn out to belong to a campaign that ended.

When to break the budget

Deliberately, in writing, with an expiry date. "We are shipping the chat widget for the launch; it costs 1.8 s on mobile; we remove or replace it by 1 March." That is a trade-off. Silently exceeding it is a regression.

The difference between a team that stays fast and one that does not is almost never knowledge. It is whether the slow version can reach production without anybody noticing.