Web2 min read

Set the performance budget before you open the design tool

Performance work after launch is remediation, and remediation is expensive. Deciding the budget at the start changes what gets designed in the first place.

Written by
Content ManagerContent Manager
Published
August 17, 2026
Last revised
September 7, 2026
Reading time
About 2 minutes

Article

Contents (5)

The usual sequence is: design, build, launch, measure, panic, remediate. The remediation phase is where someone discovers that the hero carousel loads four full-resolution images before the page becomes interactive, and that removing it means reopening a design decision everyone signed off six months ago.

A performance budget set before design turns that conversation into a constraint rather than a conflict.

#What a budget actually is

Not a target. A constraint with a number, agreed in advance, that a build cannot exceed without an explicit decision to exceed it.

A workable starting point for a content site:

MetricBudget
Largest Contentful PaintUnder 2.0s on a mid-range phone, 4G
Interaction to Next PaintUnder 150ms
Cumulative Layout ShiftUnder 0.05
JavaScript, compressedUnder 120KB on the critical path
Web fontsTwo families, four files, self-hosted

The numbers matter less than the fact that they exist and that everyone agreed to them before there was anything to defend.

#The test device is not your laptop

Measure on a mid-range Android phone on a throttled connection. That is not pessimism, it is the median. A site that is fast on a developer's machine on office wifi has been tested under conditions almost none of its users experience.

#What the budget changes

Once a budget exists, decisions that used to be aesthetic become arithmetic.

A carousel costs four images and a JavaScript library. A single well-chosen image costs one image. If the budget is 2.0s LCP, the carousel has to justify itself against that number, and the conversation is about evidence rather than taste.

Web fonts are the same. Every family is two or three files. Self-hosting removes a DNS lookup, a TLS handshake and a third-party dependency, and it usually removes a privacy conversation as well.

#Enforce it in the pipeline

A budget nobody measures is a preference. Put it in CI:

yaml
- name: Performance budget
  run: |
    npx lighthouse-ci autorun \
      --collect.settings.preset=perf \
      --assert.assertions.largest-contentful-paint="error, maxNumericValue=2000" \
      --assert.assertions.total-byte-weight="error, maxNumericValue=1200000"

Now exceeding the budget fails a pull request. That is the whole mechanism. It works because it moves the conversation from "should we fix this" to "we cannot merge this until we decide", which is a much shorter conversation.

#The honest caveat

Budgets do not survive contact with a marketing team that needs a tag manager, three tracking pixels and a chat widget. That is not a technical failure; those things may genuinely be worth their cost.

What the budget gives you is the ability to say what that cost is, in milliseconds, before it is added rather than after. Sometimes the answer is still yes. It is a better yes.

Tagged

  • performance
  • core-web-vitals
  • process

Share this article

A permanent link and an email link, rather than a row of share buttons. A share widget would mean loading somebody else’s script — and their tracking — on every article you read here.

Continue reading