Before I write to a retailer, I look at their site the way a customer does. This week that meant seven home pages, all brands I respect, run through a simulated mobile connection on a Tuesday afternoon. Five of them sit on Salesforce Commerce Cloud, two of those on the headless PWA Kit stack. One is on Shopify. One is a custom build.
I am not going to name them. The point is not to embarrass anyone. The point is that the same four problems showed up over and over, and none of them were the problems the teams probably think they have.
The numbers
Google wants the main image on a page to appear within 2.5 seconds on a phone. One of my seven hit that. The rest ranged from 9.5 seconds to 14.9 seconds. Two home pages weighed more than 14 megabytes. One weighed 20.
The best score of the afternoon, an 85 out of 100, belonged to the Shopify site. The worst, a 27, belonged to a headless Commerce Cloud build that is supposed to be the fast option.
I want to be careful here. These are single runs on a simulated device, not field data from real customers. Run the same test tomorrow and the numbers will move a little. The pattern will not.
Four things I saw
The weight is in your own images. The 20-megabyte home page was not heavy because of tags. It was heavy because the hero carousel loaded every slide at full size, and the reviews widget pulled in a few hundred thumbnails nobody will scroll to. A headless build makes this easy to fix. It also makes it easy to ship without noticing.
Two vendors doing one job. One site loads two site-search products on the same page. My guess is a migration from one to the other was started, got to the point where the new one worked, and the old one never came out. The phone's main thread was blocked for 2.4 seconds. That is the customer's thumb doing nothing while the page decides which search engine to listen to.
A speed vendor installed, and a 15-megabyte page anyway. One site has a performance optimization service in the stack. It is working as designed. It cannot shrink images the site insists on sending, and it cannot reorder tags the site insists on loading first. Tools optimize what you give them.
Layout shift on a headless build. Cumulative layout shift measures how much the page jumps around while it loads. Google's limit is 0.1. One headless site came in at 0.28. On an old template storefront I would blame a promo banner injected by a marketing tool. On a headless build, that shift is almost always in the storefront code itself: an image without dimensions, a font swap, a component that renders before its data arrives. It is fixable in days, and it is nobody's fault but the build's.
The one that was fine
The Shopify site was quick, light, and stable. I would not have written to them about speed. I wrote to them about something I could not see from the outside, which is how their subscription flow behaves after checkout. The point is that the outside-in look told me what not to pitch. That is worth as much as the findings.
What I would check Monday
If you run a storefront and have not done this lately, three things, in order.
- Open your home page in Chrome, open the developer tools, and look at the total transfer size. If it is over 5 megabytes on the first load, you have an image problem before you have anything else.
- List every third-party script that loads before the main image appears. For each one, ask who owns it and whether it still earns its place. You will find at least one that nobody claims.
- Run Lighthouse on your three highest-traffic pages, not just the home page. Product pages are usually worse.
None of this requires a replatform. Most of it does not require a vendor. It requires someone senior looking at the page the way the customer does, and then two weeks of unglamorous work. That is the kind of work I like.