Speeding up a Shopify store with an external service: what can go wrong

At the end of August, a client of mine, a fashion store on Shopify, reopened after the summer break. A week later, anyone opening the home page still saw the closing notice, with its promise that orders would ship on our return. The banner had been removed from the Shopify admin days earlier, but for visitors it had never gone away.

Shopify had nothing to do with it. The store ran through an external speed-optimisation service, one of those you switch on without touching the theme and that promise green Core Web Vitals. Within a few weeks I found two different problems with the same root, and the client decided to disconnect it.

I’m not naming the service: several products in the category use the same model, and the risks I describe apply to all of them.

How services that speed up your site on the fly work

They sit between the store and the visitor. The domain no longer points to the platform but to a proxy, almost always built on Cloudflare, which receives the page from the origin, rewrites it and hands it to the browser. On the way it compresses images, delays scripts, caches the HTML, adds lazy loading and sometimes generates meta tags and structured data.

On paper it’s convenient. But the code that reaches customers is no longer the theme’s code, and nobody on the team reads it unless they go looking for it.

On Shopify there’s an aggravating factor. The platform already runs on Cloudflare, with its own CDN and cache, and in its help centre it states that proxies in front of the domain are not supported and can interfere with the site. If something breaks, Shopify support sends you back to the proxy provider.

First incident: a cache that never expired

I made ten consecutive requests to the home page and all ten returned the same copy, saved a week earlier. The response headers were clear: the page came from the cache, it was seven days old, and the rule in place allowed it to be kept for 24 days.

The service’s sales pitch talked about a dynamic cache refreshed every few seconds. The real configuration was tens of thousands of times longer.

The few requests that escaped the cache showed the correct page, so the origin was working and the blockage was entirely downstream. The problem affected the home page and static pages, while collections and the cart were fine. That’s why nobody had noticed: people who work on the store look at products, not the home page.

A wrong banner is the lucky case, because at least you can see it. With the same rule, price changes, availability and promotion copy also stay frozen for weeks. The client edits, checks from the admin and finds everything right, while visitors see the old version.

Second incident: product photos that disappeared

A few weeks later the client wrote to say that when they opened a product page the images didn’t show. The photos were all there and the server returned them without errors. The fault was in how they reached the browser.

The service rewrote the HTML: in place of each photo it put an empty placeholder and moved the real address into an attribute. Putting the photo back in its place was left to a JavaScript library downloaded from an external public CDN, and the page had no fallback.

I checked by opening the product page in an automated browser with that CDN blocked. On desktop and mobile the gallery was a set of empty boxes. With the library loaded, the page looked perfect.

It takes very little for the script not to arrive: an adblocker, the content filters in Safari or Brave, a company network that blocks CDNs, a slow connection that times out. At that point a clothing store’s product page is a page with no clothes.

There’s also a paradox. Browsers have handled lazy loading on their own since 2019 with a simple HTML attribute, and the client’s theme was already using it. Redoing it in JavaScript adds a dependency and brings no advantage. Applying it to the main image makes things worse for the very metric these services promise to improve: an analysis published by Google on web.dev found that sites with lazy loading tend to have a worse LCP, and that the problem goes away when images visible on load are loaded immediately.

Two layers doing the same job

The two incidents have the same origin. Shopify already has a CDN, a cache and a theme with its own lazy loading. The external service adds a second layer on top that redoes the same things without knowing the store: which pages must stay up to date, which images are needed right away, what must not be touched.

Meanwhile, whoever runs the site loses visibility into what’s going on. With the banner, the client had done everything right and had no way of knowing it. With the photos, the fault appeared only on some devices, so anyone checking from their own never saw it.

These services sell a score, and the score is measured in a lab: a page loaded once, from a clean browser, on a fast network. Buyers arrive with an adblocker on, from a phone on the subway, and come back to the same page a week later. That’s where the two layers step on each other’s toes.

How to tell whether your store has the same problem

You don’t need a developer for the first checks.

In the browser’s developer tools, Network tab, look at the home page headers. A cache age of days and a very high s-maxage mean your changes aren’t getting through.
Compare the page served from your domain with the one at the .myshopify.com address. If the HTML is different, someone is rewriting it.
Open a few product pages with an adblocker on and from a network other than your own.
Before judging speed, look at the real Core Web Vitals in Search Console, not just the PageSpeed score.

If you find a layer in the middle that you didn’t know you had, ask whoever installed it which rules it applies and who checks them.

Where speed is really won

The client decided to serve the site directly from Shopify. The work on speed stays where it has always been: in the theme, in installed apps that load scripts on every page, in the weight of the uploaded images. It’s less convenient than a service you switch on with one click, but the code that reaches customers is code you can read and fix.

If you’d like an opinion on your site, tell me about your project.