Skip to content
Script&TheoryEST. 2012
§00 / JOURNAL · PERFORMANCE · OCTOBER 2026 · 5 MIN READ

Performance budgets: keeping a fast store fast.

Speed work fades if nothing protects it. How budgets turn a one-off optimisation into a standard.

FIG. 01 — DRAFTING HEADLINES

The regression problem

A store is optimised, scores improve, and six months later it is slow again. New apps, tracking tags, larger hero images and new sections each add a little weight. No single change looks harmful, so nobody notices.

What a budget is

A performance budget is a set of limits agreed in advance: total page weight, JavaScript size, number of third-party requests, and target Core Web Vitals on key templates. New work has to fit inside the budget or justify why it should grow.

Measure the right things

Core Web Vitals measure what visitors feel: how quickly the main content appears (LCP), how quickly the page responds to input (INP) and how much the layout jumps (CLS). Field data from real visitors is the goal; lab tests are how we catch problems before they ship.

Make it automatic

Budgets only work when they are checked without anyone remembering to. We add checks to the release process so a change that breaks the budget is flagged in review, alongside code quality and accessibility checks.

Leave room for the business

Budgets are not there to block marketing. When a new tool is genuinely valuable, we look for a lighter way to load it, or agree to spend part of the budget on it deliberately. The point is that the trade-off is a decision rather than an accident.

§09 / NEXT COMMIT

Send us
the brief.

A new store. A difficult migration. The thing your current stack can’t do.
Let’s make a plan.

team@scriptandtheory.com
project-brief.configREQUIRED FIELDS *