Shopify Site Speed: What Actually Slows a Store Down
It is almost never the theme, and almost always what has been added to it since.
Loading Article banner
Almost every Shopify store gets slower over time, and almost none of them get slower for the reason the owner assumes. The theme is rarely the problem. What has been added to the theme since launch usually is.
Apps do not only run where you use them
Most Shopify apps inject JavaScript into every page of the store, not only the pages where the feature appears. A review widget used on product pages loads on the homepage, the collection pages and the cart. A popup that fires once per visitor loads everywhere so it can decide whether to fire.
A store with fifteen apps can be loading a dozen scripts on a page that uses none of them, and each one has to be downloaded, parsed and executed before the page finishes.
This accumulates invisibly. No single app makes the store slow. Fifteen of them do, and the fifteenth is the one that gets blamed.
What Core Web Vitals actually measure
Largest Contentful Paint is how long until the biggest thing on screen appears, usually the hero image or the main product photograph. Slow LCP is usually an oversized image or a render-blocking script.
Interaction to Next Paint is how quickly the page responds when somebody taps something. Poor INP is usually JavaScript occupying the main thread.
Cumulative Layout Shift is how much the page moves while loading. It is usually images without dimensions, or a banner injected above content after it has rendered.
They matter modestly for ranking and considerably for conversion, which is the better reason to care about them.
The order to fix things in
Images first. They are the largest thing on most pages and the easiest to fix: correct formats, correct sizes, dimensions set so nothing shifts, and lazy loading for anything below the fold.
Then the app audit. List every app, what it loads, where it loads, and whether the business still uses it. Stores routinely carry apps installed for a campaign two years ago that are still loading on every page.
Then the theme. Render-blocking scripts in the head, fonts loading late, and code from previous developers that no longer does anything.
Then the third parties. Analytics, chat, pixels, heatmaps. Each one is a network request to somebody else's server, and each is a dependency on their uptime as well as their speed.
What speed will and will not fix
Speed is one of the things that decides whether a Shopify store converts the traffic it already has, and it is the one most often blamed for problems that belong to the product page. A faster store converts better, particularly on mobile and particularly on slower connections, and it removes an obstacle to ranking. What it does not do is make a page rank that has no content, no links and no reason to be preferred.
Speed is a hygiene factor. It stops you losing rather than making you win, which is a reason to fix it and not a reason to spend a quarter on it. It is one part of the technical work rather than the whole of it.
What to measure, and where
Lab tools such as PageSpeed Insights give a repeatable score from a simulated device, which is useful for comparing before and after a change and useless as a measure of what customers experience.
Field data, the Core Web Vitals report in Search Console, is what real visitors on real devices experienced over the previous month. It is the number Google uses and it lags, so a fix made today shows there in weeks rather than immediately.
Speed is one of several things that decide whether a Shopify store converts the traffic it already has, alongside the product descriptions and the structured data that shape the result somebody clicked. It matters differently on a marketplace, where Amazon and Walmart serve the page and you supply the content inside it. Use both and expect them to disagree. Lab data tells you whether a change worked; field data tells you whether it mattered. A store that scores poorly in the lab and passes in the field is serving customers who are mostly on fast connections, and the reverse is far more common and more urgent.
Where this goes next
Speed is one of five things that decide whether a store ranks, and the others are on the same list. Why collection pages do not rank is the second most common fault after speed on a store that has been themed and left. Structured data is what makes a fast page show a price and a rating in the result. Supplier descriptions cost rankings on pages that load in under a second. And before any of it, store SEO and marketplace optimisation are not the same job, which is where a brand selling on both usually starts in the wrong place.
Keep reading
Frequently asked questions
The questions that come up most often on this subject.
Shopify's own infrastructure is fast and is rarely the constraint. What the platform does limit is control: you cannot remove its core scripts or change how apps inject theirs, so optimisation is largely about what you add rather than about the platform underneath.
Below the fold, yes. Above the fold, no. Lazy loading the hero or main product image delays the Largest Contentful Paint, which is the opposite of the intended effect and a common mistake when lazy loading is applied site-wide by a plugin.
After any app install or theme change, and monthly otherwise. Speed regresses gradually through accumulation rather than suddenly, so a scheduled check catches it while it is still one app rather than five.
Considerably. Most eCommerce traffic is mobile, mobile devices parse JavaScript more slowly, and mobile connections are less reliable. Google's Core Web Vitals assessment is also based on mobile, so the mobile number is the one that counts.
Usually the accumulation of apps rather than the theme. Most apps inject JavaScript into every page rather than only the pages where their feature appears, so a store with fifteen apps loads a dozen scripts on pages that use none of them. Oversized images are the other common cause.
They are a ranking input and a modest one compared with relevance and authority. Marketplaces weigh speed differently again, because the page belongs to them rather than to you: <a href="/services/marketplace-management/amazon">Amazon</a> and <a href="/services/marketplace-management/walmart">Walmart</a> own the markup on their own pages. They matter more for conversion: mobile shoppers abandon slow pages regardless of where those pages ranked, so the commercial argument is stronger than the SEO one.
There is no number, because apps differ enormously in weight. The useful test is whether each one is still used by the business and how much it loads on pages where its feature does not appear. Stores routinely carry apps installed for a campaign years ago that still load on every page.
Sometimes, and it is rarely the cheapest fix. A rebuild on a fast theme with the same fifteen apps and the same unoptimised images ends up in the same place. Audit what is loading first, because that answer often makes the rebuild unnecessary.
Google's thresholds are the target: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured on mobile. Most Shopify stores fail on LCP first, and images are usually the reason.
It is usually the single largest improvement available, because images are the biggest thing on most pages and the Largest Contentful Paint element is an image on nearly every product and collection page. Correct format, correct size for the display, and explicit dimensions so nothing shifts.
