Most Shopify speed advice optimises a number that nobody buying from you can see. It will tell you to compress images, enable lazy loading, and get the score green, and none of that is wrong. It just skips the question worth asking first: which part of the slowness is actually costing you orders?
This is a conversion practitioner's view of that question, not a performance engineering guide. Shopify's own developer documentation already owns the engineering side and does it better than I would. What it does not cover is why speed projects keep failing on stores that already did the compression.
The measurements that matter, and the one that misleads
The three Core Web Vitals and their "good" thresholds, from Google's own documentation:
| Metric | Good | What the buyer experiences |
|---|---|---|
| Largest Contentful Paint | within 2.5s | how long until the main thing appears |
| Interaction to Next Paint | 200ms or less | whether taps feel instant |
| Cumulative Layout Shift | 0.1 or less | whether the page moves under their thumb |
One correctness note, because a lot of Shopify speed content is stale on it: Interaction to Next Paint replaced First Input Delay and became a stable Core Web Vital in 2024. If a guide is still telling you to optimise FID, it has not been updated in two years, which tells you something about the rest of its advice.
Now the one that misleads. A Lighthouse score is a lab test on a simulated device, and it is easy to move without changing anything a buyer feels. Google evaluates field data from real visitors. So a store can go from 42 to 78 in Lighthouse, ship nothing a customer would notice, and report a successful speed project. I have seen that outcome sold as a win more than once.
Optimise the thing a buyer waits for. Then check whether conversion moved, not whether the score did.
Why speed work fails: it starts too late
The most common failure I see across Shopify projects is not a missing technique. It is sequencing. Speed gets treated as polish applied after the design is finished.
By the time a build reaches the "let's optimise performance" stage, the expensive decisions are already made. A full-viewport hero. Illustrations exported as raster images instead of SVG. An autoplay video above the fold. A scroll that flashes white because nothing reserves space. Four apps that each inject a script. At that point the only tools left are compression and lazy loading, which is why so many speed projects end with a slightly faster version of a page that was structurally heavy by design.
Specific things I keep finding at that stage, in rough order of how often:
- High time to first byte that predates the redesign. Nobody checks it before rebuilding on top of it. This one is a developer's problem, not mine, and it needs to be found before the design work rather than after.
- Raster illustrations where an SVG would do. Line art and icons exported as PNG, often at 2x, often several hundred kilobytes each for something that would be a few kilobytes as vector.
- Janky scroll that flashes white. Content that does not reserve its space. This is a Cumulative Layout Shift problem and it is also just unpleasant, which is the part that costs you.
- Autoplay video above the fold. Which brings us to a related argument.
The video argument, which is not really about speed
I will usually push back on a product page video in favour of a static screenshot, and page weight is only the third reason.
The first two: a video raises questions the buyer has to resolve before they get value from it. How long is this? Do I need to pause it to read the detail? A static image of the thing, annotated, delivers the same information in the time it takes to glance. And a video that has to be watched competes with the buying decision rather than supporting it.
Then, yes, it hurts load speed. But if the only argument you have against the video is page weight, you will lose that argument to a client who cares about the brand feel, and you will deserve to. The stronger case is that it is worse at its job.
The heavy hero is a hierarchy problem wearing a speed costume
On collection pages especially, the biggest single element is often a decorative hero, and the instinct is to compress it.
The better question is why it is there. The point of a collection page is getting a visitor to the products as fast as possible. An oversized hero on top of a product grid is basically noise: it pushes the only thing the page exists for below the fold and costs you your Largest Contentful Paint at the same time.
Compressing that image gives you a fast version of a page that still delays the products. Removing it fixes both problems at once, and that is the general shape of the highest-value speed work: the fix is frequently deletion, not optimisation. It is also why this work belongs to whoever owns the page hierarchy rather than to whoever owns the build pipeline.
Two related traps on the same surface:
- Search-engine copy blocking the path to product on collection pages. It does not have to go, but it can fade or sit in an accordion so it stays crawlable without delaying the click.
- Whitespace that reads as the end of the page. Not a speed issue at all, but it produces the same business outcome as a slow page: people do not reach the products.
Apps: audit what they earn before you audit their size
Most Shopify apps add scripts to every page, whether that page uses the feature or not. The usual advice is to remove the ones you do not need, which is correct and insufficient.
The more expensive pattern is overlap: several apps doing the same job, so you load several scripts to deliver one feature. I have opened stores running multiple bundle apps simultaneously, and the honest description is that it is a bit of a mess: conflicting cart behaviour, duplicate scripts, and nobody able to say which one is producing the revenue.
So audit apps by what each one earns first, then by what it costs in weight. An app pulling real attach rate is worth its script. Three apps splitting one feature between them are not.
What is not my job, and what to do about it
Being direct about scope, because this is where a lot of speed advice oversells.
If your time to first byte is bad, your theme's Liquid is doing expensive work in loops, you need server-side rendering decisions, or your app stack needs untangling at the code level, that is a developer's job. I will tell you that rather than pretend a design pass will fix it, and it is worth knowing before you hire anyone that those are two different engagements.
What I do work on is the part that produced the weight: what went on the page, in what order, and whether the thing your Largest Contentful Paint is waiting for is a product or a decoration.
How to sequence it, if you are starting now
- Get field data before opinions. Real-visitor Core Web Vitals, not a Lighthouse run on your laptop over office wifi.
- Find what your Largest Contentful Paint element actually is. On a lot of Shopify stores it is a decorative image. That single fact usually reframes the project.
- Ask what each heavy element earns. Delete, then compress. In that order, because compressing something that should not exist is wasted work.
- Check time to first byte separately and hand it to a developer if it is bad. Do not design on top of a slow server.
- Measure conversion, not score. Over a window you set in advance, on the metric that matches the change.
On step five, the same caveat applies here as everywhere else: a meaningful A/B test needs roughly 200 to 250 conversions and about 5,000 sessions per variation. Most stores doing $50k to $1m a month cannot isolate a speed change that way, so you measure a clean before-and-after and you say out loud that is what you are doing.
A note on the statistics you will see quoted
Every speed article cites a figure connecting milliseconds to revenue. I have deliberately not quoted one, because when I went looking for primary sources behind the famous ones, most trace back to vendor blog posts, consultancy marketing, or each other.
What is verifiable is Google's published thresholds above, and the plain mechanism: a person waiting on a page they did not want to wait on is more likely to leave. That is enough to justify the work. You do not need a borrowed statistic with no source behind it, and quoting one costs you credibility with the exact technical buyer who checks.
Related reading: The Complete Shopify CRO Guide · Shopify Checkout Optimization · Conversion rate optimization audit
If you want to know whether your slowness is a design problem or a developer problem before you pay anyone to fix it, book a free 30-minute call. I will tell you which one it is, including when the answer is that you need an engineer and not me.
