Speed is a revenue input, measured on real users
Slow stores convert worse, rank worse, and pay more per ad click. And store speed decays by default — every app install and campaign script pushes it the wrong way.
Speed work fails in two common ways: optimising a lab score that real users never experience, and fixing things once while the causes of decay keep operating. Ops runs speed as a continuous discipline instead — real-user Core Web Vitals segmented by template and device, causes identified rather than symptoms, fixes applied at the edge or handed to Builder, and a baseline that catches regressions when they arrive.
Measure what shoppers experience
A synthetic score from a test server says little about a shopper on a mid-range phone on cellular. Real-user data, split by template, is what localises the problem to something fixable.
Real-user LCP, INP, and CLS per template — product, collection, home, checkout
Device and network splits, where the real damage usually concentrates
Third-party script cost, attributed per script rather than in aggregate
The gap between lab scores and field data, which is itself diagnostic
Fix causes, at the right layer
Some problems are edge problems — caching, image delivery, compression — and Ops fixes those directly. Some are page problems — render-blocking scripts, oversized media, layout shift from late-loading elements — and those go to Builder as specific tasks with the evidence attached.
Regression is the default; prevent it
The store that was fast in March is slow by August because of accumulated installs and scripts. The baseline makes decay visible immediately: when a new app or theme update pushes a template’s metrics down, it is flagged that week, with the cause attached, not discovered in a quarterly audit.
How it works
Baseline per template
Ops records real-user metrics by template and device — the reference every later change is judged against.
Fix by layer
Edge problems are fixed in configuration; page problems go to Builder with the specific evidence.
Watch for decay
New scripts, apps, and theme changes are checked against the baseline and flagged when they cost speed.
What you get
Field metrics by template and device instead of a single lab score
Third-party scripts held accountable for what they cost
Fixes applied at the layer that owns the problem
Regressions caught the week they happen, with the cause attached
Handled by these agents
Frequently asked questions
Which metric matters most for a store?
LCP on product and collection templates is usually where revenue is most exposed, with INP close behind on interaction-heavy pages. But the honest answer is: whichever one is worst for your real users on their actual devices.
Will removing apps break functionality?
The audit distinguishes scripts that earn their cost from those that no longer do. Removal is proposed with the evidence, and staged so anything genuinely load-bearing is caught before it matters.
How much does speed actually affect conversion?
Enough that the effect shows in your own data — which is the measurement that matters, rather than an industry statistic. The baseline lets you see your own elasticity instead of quoting someone else’s.
Does this help SEO too?
Yes — page experience signals feed rankings, and faster pages get crawled more efficiently. But the conversion effect usually pays for the work before the ranking effect arrives.
Keep reading
Improve store page speed
A field-data-first speed programme: measure real users, fix by layer, prevent regression.
Improve mobile conversion
Close the mobile gap: thumb-reach reality, speed on real devices, and checkout friction.
Conversion rate optimisation
Find where the funnel leaks, fix the cause, and measure whether it actually moved.
A/B testing
Test the genuinely uncertain decisions, sized honestly, instead of testing everything badly.
Put the team to work on your store
Connect your storefront, analytics, and email stack, set a goal, and let the agents run the work end to end. Start on the free plan with your own model key.