Performance Culture
Date: 2026-08-17
Making performance someone’s job before it becomes everyone’s emergency. Performance decays by default — every individual addition is reasonable, and the sum of reasonable additions is a slow site — so the question isn’t how to make a site fast but how to stop it getting slow again.
Performance culture is the set of ownership, budgets, checks and routines that keep a site fast after the initial optimisation work is done.
The cycle
Recognisable in almost every organisation, and the fixes people reach for address the wrong part of it.
1 site is slow "we should do something"
2 a project is funded a sprint, a consultant, a push
3 numbers improve dramatically everyone is pleased
4 attention moves on no gate, no owner
5 decay resumes one reasonable addition at a time
· a chat widget
· a personalisation script
· an untuned hero image
· a library for one date function
6 eighteen months later → step 1
Step 4 is the failure, not step 5. The optimisation project worked; nothing was put in place to hold it. A team that ships a performance push without a budget and an owner has bought eighteen months, not a fast site.
Why decay is the default
The incentives all point one way:
- Every addition has a named beneficiary; the cost is diffuse. The chat widget has an owner who wants it. The 90ms it adds is charged to nobody
- The people who decide have fast devices and fibre. A page that takes 1.2s on a MacBook takes 6s on a mid-range Android on 4G, and that device is never in the room — Field vs Lab Data
- Nobody’s objective is “the site didn’t get slower”. It’s a non-event, and non-events don’t get reported
- Third parties arrive through non-engineering routes — marketing adds a tag, and the tag manager exists precisely so that no engineer has to approve it — Tag Manager Performance
- Regressions are invisible for weeks and then unattributable — Performance Regression Testing
What actually holds
Ranked by how much they survive contact with a busy quarter:
1. An automatic gate. A budget that fails a build is the only mechanism that works without anyone remembering. Everything else depends on attention, and attention is the resource in shortest supply — Performance Budgets.
2. A named owner. Not a team, a person, with it in their objectives. Unowned performance is nobody’s Tuesday priority.
3. Making the cost visible at the point of decision. A bundle-size delta in the pull request. A “this tag adds 140ms” line in the request form for a new third party. Most regressions don’t survive being seen — Bundle Analysis.
4. Field data segmented by device, in front of the people deciding. The p75 Android number, monthly, next to the revenue number — Real User Monitoring, Percentiles in Performance.
5. A device to test on. One cheap Android phone on the desk changes more minds than any dashboard.
The argument that gets it funded
Engineering arguments don’t win budget. Money does, and the honest version is available:
✗ "our largest contentful paint (LCP) is 3.8s, should be under 2.5s"
→ a technical fact with no consequence attached
✓ "product-page LCP is 3.8s at p75. our own measurement puts
the conversion cost at roughly £X per 100ms. closing the gap
to 2.5s is worth an estimated £Y a year, and the work is Z weeks"
→ an investment case
Measure the relationship on your own site rather than citing someone else’s figure. Published performance-conversion numbers come from different sites with different customers and different baselines, and quoting them invites a fair objection you can’t answer. Your own data — segmented, or ideally from a deliberate test — is defensible — Performance and Conversion.
Where the number can’t be measured, say so and use the borrowed figure explicitly as an assumption. That’s an honest framing that survives scrutiny; presenting someone else’s benchmark as your own doesn’t.
Governance that isn’t a blocker
The failure mode of taking this seriously is a review board that everyone routes around.
- A default budget with an exception process, not case-by-case approval. Under the line, ship; over it, a conversation
- Third-party requests get a measured cost, not a judgement. Load it on a staging page, measure, attach the number to the request — Third-Party Scripts
- A quarterly third-party audit, removing tags nobody claims. There will be several, and there always are
- Performance in the definition of done for front-end work, at the level of a checklist item rather than a sign-off
- Own the metric, not the implementation. Teams should be free to hit the budget however they like
The signals it’s working
✗ "we're doing a performance sprint" ← the cycle, restarting
✗ a dashboard nobody opens
✗ a Lighthouse score in a deck
✓ a PR closed because it blew the budget
✓ someone asking "what does this add?" before adding a tag
✓ the p75 mobile number quoted in a business meeting by
someone who isn't an engineer
✓ a third-party request withdrawn after being measured
The clearest single indicator is the first one: performance has authority over a shipping decision, rather than a voice in it.
Where it interacts
- Performance Budgets — the mechanism this note argues is the only durable one
- Performance and Conversion — the commercial argument, and how to estimate it defensibly
- Third-Party Scripts — the largest source of decay, and the one furthest from engineering control
- Experimentation Maturity — the same shape of problem in a different domain, with the same answer: move the discipline into the platform rather than relying on people remembering