When the store is slow and nobody can say why
Slow stores are rarely slow for the reason people assume. The theme gets blamed because it’s the thing that was bought most recently, and it’s usually not the largest contributor.
What’s actually costing the seconds, in roughly the order I find it: apps that load on every page whether or not they’re used there; images uploaded at the size the camera produced them; a third-party script somebody added for a campaign that ended; and only then, sometimes, the theme.
The reason it goes unfixed is that it doesn’t present as a speed problem. It presents as a bounce rate, or a mobile conversion rate that’s worse than desktop and has been for so long it looks normal. Nobody files a ticket saying “the site is slow.” They just leave.
Check it yourself, in five minutes
Open PageSpeed Insights and run your busiest collection page and a product page. Not the homepage — the homepage is the page everybody optimises and the one fewest customers land on.
Read the mobile number first. Desktop flatters everything.
Scroll past the score to Largest Contentful Paint and Cumulative Layout Shift. LCP over 2.5 seconds and CLS over 0.1 are the two that cost money. If there’s field data from real visitors, trust it over the lab score.
Then open your own store on your own phone, on mobile data, not wifi. Count the seconds before you can tap something. That number is what your customer experiences, and it’s the only one that matters.
What the work involves
Measurement first, on the pages that carry money — not the homepage, and not a single run.
Finding what’s actually responsible, which usually means auditing the app stack before touching the theme. The cheapest fix is often removing something rather than optimising it.
The implementation — image handling, what defers, what loads conditionally, what renders server-side, and the theme-level work where the theme is genuinely at fault.
A re-measurement afterwards, on the same pages, published to you. A performance engagement without a before and after is an invoice with a story attached.
A budget you can hold going forward — a number, so the next app has to justify itself against something.
What this isn’t
It isn’t a guarantee of a score. I can’t promise a 95 on a store whose business needs a review widget, a chat app and three tracking pixels — what I can do is make the trade-offs visible so they’re decisions rather than accidents.
It isn’t a conversion guarantee. Faster stores usually convert better. Yours might be slow and have a different problem, and I’d rather find that in the audit than after the invoice.
It isn’t ongoing. This is a fix, not monitoring. If what you want is someone watching it over time, that’s a conversation and it isn’t packaged.
And some of it genuinely can’t be fixed-price — occasionally I can’t tell how deep something goes until I’m in the code, and I’ll say that rather than pad the estimate to cover it.
What the standard says about this
- A performance target that holds as content grows — Whether the store is fast on the pages that carry real content, measured in numbers rather than impressions.
- Every app's cost, decided deliberately — Whether anyone costed the apps before installing them.
- Rendering that doesn't make the shopper wait — Whether Liquid, scripts and third-party code delay the content the shopper actually came for.
Two ways to find out
The checks above are published and free. Run them yourself, or send me the store and I'll run them for you.