Setting a performance budget for a Shopify store

No store gets slow overnight. It gets slow one reasonable decision at a time — an app here, a widget there, a hero video someone in marketing wanted. Each is defensible in isolation and the total is a store nobody enjoys using.

A performance budget is a written limit that makes each of those decisions visible before it's made.

What to put in it

Keep it short enough that people remember it. Four numbers:

That last row is the one that does the work in practice, because it's countable by someone non-technical and it maps directly to "can we install this app?"

Some teams add total page weight and JavaScript bytes. Useful for developers, less useful as a shared rule.

Realistic numbers

Don't set a budget you'll ignore in week two.

• Field data over lab scores. Field data is what counts.
• Measure your current state first, then set the budget slightly better. A store at 4s LCP should target 3s, then 2.5s — not 1.8s.
• Per template, not site-wide. Home, collection, product each have their own realities.

Who owns it

The part that decides whether it works. A budget nobody owns is a document.

• Someone signs off on anything that adds weight — a new app, a new script, a new font.
• The question is asked out loud: what does this cost, and what does it earn?
• Measurement is scheduled, monthly, not "when someone complains".

In small teams this is one person. In larger ones it belongs with whoever owns conversion, because that's whose number suffers.

Enforcing it during development

• Run Lighthouse on key templates before merging a theme change.
• Run `shopify theme check` in CI, which catches several performance patterns automatically.
• Measure any new app on a duplicate theme before it goes live — install, measure, compare, decide.
• Re-measure after launch with field data.

The app rule

The most useful single policy: installing an app means measuring before and after.

If it adds more than a couple of tenths of a second, it needs a reason beyond "it looked useful". And run a review twice a year asking two questions of every app — do we use it, and is the value greater than its cost in money and speed?

Most stores can remove several. How many apps is too many covers what's usually replaceable.

Design decisions are budget decisions

Worth saying to designers explicitly, before a design is signed off rather than after:

• A full-bleed hero image is the LCP element. Its size is a design decision with a measured cost.
• Each extra typeface and weight is a file.
• Carousels load every slide.
• A section-per-scroll layout with a large image each is heavy by construction.

The budget belongs in the design brief — the theme performance checklist is a design document as much as a technical one.

Reviewing it

Once a quarter:

• Are we within budget on each template, in field data?
• What was added since last time, and what did it cost?
• What can come out?

If you've drifted, the review tells you exactly which decision caused it — which is the whole point, and it's much easier than an archaeology exercise a year later.

When to break it

Deliberately, and with a note. If a feature genuinely earns more than the speed it costs, that's a legitimate trade — as long as it's a decision rather than an accident. The budget's job isn't to say no; it's to make sure someone said yes on purpose.

A performance budget doesn't make a store fast. It stops a fast store getting slow, which is the harder problem and the one nobody plans for.