Key takeaways
- Core Web Vitals are a confirmed Google ranking input, and since March 2024 INP has replaced FID as the responsiveness metric. “Good” means LCP under 2.5s, INP under 200ms, and CLS under 0.1.12
- Speed is a conversion lever, not just an SEO one. A 0.1s mobile speed gain lifted retail conversions by 8.4% and average order value by 9.2% in the Deloitte and Google study.3
- The web passes all three Core Web Vitals on only 43% of mobile page loads. INP is the hardest metric to pass, and it is where app-heavy Shopify stores feel the most pressure.4
- The biggest drag on a Shopify store is rarely the platform. It is stacked app JavaScript, third-party widgets, heavy hero media, and layout that shifts as late scripts load.
- Native theme code avoids the per-visit app runtime tax. In our own testing, drag-and-drop builders ran 22-37% slower than native-code equivalents.
Every few months a merchant sends me a PageSpeed score, usually a red one, and asks the same question: is this Shopify, is this my theme, or is this the twelve apps I installed last year? This piece is my attempt at an honest, sourced answer to the broader version of that question. Where does Shopify storefront performance actually stand in 2026, what are the real Shopify performance benchmarks, and what is dragging most stores down?
Short version: the platform floor is solid and getting better, the measurement bar has moved, and almost all of the pain that lands on real stores comes from what merchants bolt on top.
Why you can trust us
Over 15 years of development experience and four years inside the Shopify ecosystem. We have measured Core Web Vitals across 500+ Shopify stores and rebuilt themes specifically to recover speed lost to apps. We also build Fudge, an AI store editor that writes pages directly into your theme as native code rather than rendering them through an app runtime. That design choice came straight out of this performance problem, so we will flag the bias where it is in play.
Why store performance matters more in 2026
Two forces make speed a first-order concern this year rather than a technical nice-to-have.
Core Web Vitals are a ranking input, and the metric set changed
Google uses Core Web Vitals as part of its page experience ranking systems.2 That has been true for a while. What changed more recently is the metric set itself.
In March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness Core Web Vital.1 FID only measured the delay on a user’s first interaction. INP measures the latency of interactions across the whole visit, so it captures the sluggish taps, laggy menus, and slow add-to-cart responses that FID quietly ignored. It is a harder bar, and it is a truer one.
The three thresholds for a “good” experience, measured at the 75th percentile of real page loads, are:
- LCP (Largest Contentful Paint): 2.5s or under - how fast the main content paints
- INP (Interaction to Next Paint): 200ms or under - how responsive the page feels to input
- CLS (Cumulative Layout Shift): 0.1 or under - how much the layout jumps around while loading2
These are the official Google thresholds. A page that misses them is not disqualified from search, but it is competitively disadvantaged against stores that pass.
Speed moves conversion, with real money attached
The ranking case is only half the argument. The other half is that faster stores sell more.
The most cited controlled study here is the Deloitte and Google “Milliseconds Make Millions” report, which measured 37 brand sites across more than 30 million sessions. A 0.1 second improvement in mobile load time lifted retail conversion rates by 8.4% and average order value by 9.2%.3 That is a tenth of a second producing a near-double-digit revenue swing.
For a sense of scale on the checkout end, Shopify’s own commissioned research puts its checkout conversion at up to 36% higher, and 15% higher on average, than competing checkouts.5 The platform has done real work on the parts it controls. The storefront in front of that checkout is where most merchants still leave money on the table.
For the category-by-category picture on where conversion sits, see our Shopify conversion rate benchmarks.
The Core Web Vitals thresholds, and how the web is doing
Before looking at Shopify specifically, it helps to know what “normal” looks like across the whole web, because Shopify stores are graded on the same curve.
The HTTP Archive Web Almanac, which analyses millions of real origins, found that in 2024 only 43% of websites passed all three Core Web Vitals on mobile.4 Here is the per-metric breakdown:
| Core Web Vital | ”Good” threshold (P75) | Mobile pass rate, all sites (2024) |
|---|---|---|
| LCP | 2.5s or under | 59%4 |
| INP | 200ms or under | 74%4 |
| CLS | 0.1 or under | 79%4 |
| All three | n/a | 43%4 |
Two things stand out.
First, the swap to INP made the bar harder. Under the old FID metric, 48% of mobile sites would have passed the full set in 2024. Under INP, that fell to 43%.4 The web did not get slower. The ruler got more honest.
Second, INP is improving fast but remains the pressure point for interactive sites. Mobile INP pass rates climbed from 55% in 2022 to 64% in 2023 to 74% in 2024.4 The gap between desktop and mobile is still wide, and INP is precisely the metric that heavy JavaScript degrades, because every script the browser has to parse and execute competes with the main thread that responds to taps.
Hold that thought, because JavaScript is where the Shopify story turns.
Where Shopify stores actually stand
Shopify sits above the ecommerce average on the metric the platform most directly controls. The Web Almanac’s ecommerce analysis notes that Shopify has consistently maintained good LCP pass rates since 2022, a group it shares with only a handful of platforms.6 That is not an accident. Every Shopify store runs on the same CDN, the same edge caching, and the same server-rendered Liquid, so the first-paint fundamentals are strong out of the box in a way that a self-hosted platform cannot guarantee.
Where Shopify stores struggle is the same place the rest of the interactive web struggles: INP. And here the cause is almost never the platform. It is the client-side JavaScript that merchants stack on top of it.
A quick note on honesty in the numbers. Public aggregate figures for “share of Shopify stores passing all three Core Web Vitals” vary widely between sources and measurement windows, so I am not going to quote a single headline percentage as if it were settled. The defensible, sourced claims are these: Shopify’s platform-level LCP is consistently good,6 the web-wide all-three pass rate is 43% on mobile,4 and INP is the metric under the most strain. The rest of a store’s score is determined by what the merchant adds.
The biggest drag factors on Shopify performance
Across the stores we have audited, the same culprits show up again and again. None of them is Shopify. All of them compound.
App JavaScript bloat
This is the single largest factor. The median mobile web page already ships around 570 KB of JavaScript.7 On a Shopify store running a typical app stack, that number climbs fast, because most apps inject their own script bundle on every page load, whether or not the shopper interacts with the feature.
A reviews app, an upsell app, a currency switcher, a chat widget, and a page builder can each add tens to hundreds of kilobytes. The browser has to download, parse, and execute all of it, and that execution is exactly what pushes INP past 200ms. The feature might be used by 2% of visitors. The runtime cost is paid by 100% of them.
Third-party widgets
Related but distinct: scripts loaded from someone else’s domain. Reviews, social proof popups, live chat, analytics beyond the essentials, and embedded video players all phone home to a third-party server before they render. Each adds a DNS lookup, a connection, and a payload you do not control. When that third party has a slow day, your LCP has a slow day.
Unoptimised images and hero media
Product and lifestyle imagery is the heaviest content on most storefronts, and hero media is the usual LCP element. A single uncompressed 1.5 MB hero on a mobile connection can blow the 2.5s LCP budget on its own. The fixes are unglamorous and effective: serve WebP or AVIF, size images to the device, and defer anything below the fold. Our guide on how to lazy load images in Shopify walks through the mechanics without breaking the LCP element above the fold.
Theme bloat and render-blocking scripts
Themes accumulate weight over time. Sections that are no longer used, features layered on by successive developers, and scripts loaded in the document head that block the first paint all add up. A render-blocking script in <head> forces the browser to stop building the page until it downloads and runs. Moving non-critical scripts to defer, and pruning dead theme code, is often the highest-return work on an older store. See our guide on how to speed up a Shopify theme for the specific levers.
Layout shift from late-loading elements
CLS is the metric most stores pass, but the failures are avoidable and jarring. A banner that pushes content down when it loads, an image without dimensions, a font swap that reflows text, or a cookie bar that appears after paint all move the page under the shopper’s thumb. Reserving space for late elements fixes almost all of it.
The app-weight problem: native code versus stacked widgets
Step back from the individual culprits and a pattern emerges. Nearly every drag factor above is a variant of the same thing: code that runs on the shopper’s device on every visit, to power a feature that could have been rendered once on the server.
This is the structural issue with the app-heavy model. An app that renders part of your page through its own runtime has to load that runtime for the shopper to see the result. A page builder that renders pages through an app SDK adds its bundle to every page it touches. The store pays a per-visit tax for the convenience of the editor.
Native theme code does not carry that tax. When a page is written as Liquid, CSS, and HTML directly into the theme, the server renders it exactly like any other Shopify page. There is no app SDK to download, no runtime layout to hydrate, no extra JavaScript competing for the main thread.
We put numbers on this gap in our Shopify page builder speed test. Across the 500+ Shopify stores we have analysed, sites using drag-and-drop page builders ran 22-37% slower than equivalent sites built on native theme code. The gap is architectural, not a configuration mistake you can tune away. A runtime can be pared down, but it cannot ship zero bytes.
This is the seam Fudge sits in, and the reason we built it the way we did. You describe the page, Fudge writes it into your theme as native code, and the published page has the same JavaScript footprint as one your developer hand-coded. The Lighthouse ceiling is set by your theme, your images, and your other apps, not by the builder.
What “good” looks like, and how to get there
Concrete targets for a Shopify page on mobile, measured at the 75th percentile of real users:
- LCP under 2.5s - the hero image or headline paints fast
- INP under 200ms - taps, menus, and add-to-cart feel instant
- CLS under 0.1 - nothing jumps as the page settles
- Total page weight under 1.5 MB, excluding video
The path to hitting them consistently is less exotic than most stores assume. In rough order of return:
- Audit the app stack. Uninstall anything used by a small slice of visitors, and check the theme for leftover script tags after removal. This is usually the biggest single win.
- Fix hero media. Modern formats, correct sizes, proper loading attributes. Cheap and high impact on LCP.
- Defer non-critical JavaScript and remove render-blocking scripts from the head.
- Reserve space for banners, images, and embeds to kill layout shift.
- Measure with real-user data, not a single Lighthouse run. One synthetic load can be 30% off the median. Use 75th-percentile field data from the Chrome User Experience Report or Search Console as the source of truth, and treat Lighthouse as a relative screening tool.
The recurring theme: most of the work is subtraction, not addition. The fastest stores are not the ones with the most performance apps. They are the ones carrying the least weight.
The forward view: where Shopify performance goes next
A few things I would bet on for the next year.
The platform floor keeps rising, and the gap to the app layer widens. Shopify’s server-side and CDN work has made the fundamentals strong. As the platform improves, the share of a store’s score determined by third-party JavaScript grows, not shrinks. The delta between a lean store and a bloated one gets more visible, not less.
INP stays the metric that separates good stores from average ones. LCP and CLS are increasingly solved by defaults and better themes. INP is a direct function of how much JavaScript executes on the main thread, and that is a merchant decision. Stores that treat every new app install as a performance decision will pull ahead of stores that do not.
Native-code output becomes the default expectation for storefront editing. For stores running paid traffic, where the Deloitte-style math means every 100ms of LCP maps to real ROAS,3 the question stops being “which editor is easiest” and becomes “which one adds nothing to the page.” That is a different frame than the category was sold on a couple of years ago.
The headline for 2026 holds: Shopify gives you a fast foundation, and most stores spend that head start on weight they did not need to carry. The good news is that this is the most fixable problem in ecommerce performance, because almost all of it is under your control.
FAQ
Measured at the 75th percentile of real users, aim for LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. These are Google's official thresholds. Since March 2024, INP replaced FID as the responsiveness metric, so a Shopify store that felt fine under the old rules should recheck its interactivity.
The platform fundamentals are strong. Every Shopify store runs on the same CDN and edge caching with server-rendered Liquid, and Shopify has consistently maintained good LCP pass rates since 2022 according to the Web Almanac. Most performance problems on real stores come from apps, third-party widgets, and heavy media added on top, not from the platform itself.
Almost always because of stacked app JavaScript. The median mobile page already ships around 570 KB of JavaScript, and each app you install usually adds its own bundle that runs on every visit. That execution is what pushes INP and Total Blocking Time up. Audit your app stack, remove low-usage apps, and check the theme for leftover scripts.
Interaction to Next Paint measures how quickly a page responds to interactions across the whole visit. It replaced First Input Delay in March 2024 because FID only measured the delay on the very first interaction, which understated real-world sluggishness. INP is a harder, more representative bar, and it is the Core Web Vital most affected by heavy JavaScript.
Measurably. In the Deloitte and Google Milliseconds Make Millions study across 30 million-plus sessions, a 0.1 second improvement in mobile load time lifted retail conversion rates by 8.4% and average order value by 9.2%. Speed is a conversion lever and a ranking input at the same time.
App-rendered page builders do, because they load a runtime bundle on every page they render. In our testing across 500+ Shopify stores, drag-and-drop builders ran 22-37% slower than native-code equivalents. Builders that write native Liquid and CSS into the theme add no runtime, so their pages perform like hand-coded ones.
Footnotes
-
web.dev, “Interaction to Next Paint becomes a Core Web Vital on March 12” - INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. https://web.dev/blog/inp-cwv-march-12 ↩ ↩2
-
Google Search Central, “Understanding page experience in Google Search results” and web.dev, “Web Vitals” - Core Web Vitals are used by Google’s ranking systems; good thresholds are LCP under 2.5s, INP under 200ms, CLS under 0.1 at the 75th percentile. https://developers.google.com/search/docs/appearance/page-experience and https://web.dev/articles/vitals ↩ ↩2 ↩3
-
Deloitte and Google, “Milliseconds Make Millions” (2020) - a 0.1s improvement in mobile site speed increased retail conversion rates by 8.4% and average order value by 9.2%, across 37 brands and 30M+ sessions. https://www.deloitte.com/ie/en/services/consulting/research/milliseconds-make-millions.html ↩ ↩2 ↩3
-
HTTP Archive, “Performance” chapter, Web Almanac 2024 - 43% of mobile sites passed all three Core Web Vitals (48% under the old FID metric); mobile pass rates were LCP 59%, INP 74%, CLS 79%; mobile INP improved from 55% (2022) to 64% (2023) to 74% (2024). https://almanac.httparchive.org/en/2024/performance ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Shopify, “Shopify Checkout is the best-converting in the world. Here’s why.” - Shopify’s checkout converts up to 36% higher, and 15% higher on average, than competing checkouts, per a study by a Big Three consulting firm. https://www.shopify.com/enterprise/blog/shopify-checkout ↩
-
HTTP Archive, “Ecommerce” chapter, Web Almanac 2024 - Shopify has consistently maintained good LCP pass rates since 2022, unlike platforms such as WooCommerce. https://almanac.httparchive.org/en/2024/ecommerce ↩ ↩2
-
HTTP Archive, “Page Weight” chapter, Web Almanac 2024 - the median mobile page requests roughly 570 KB of JavaScript. https://almanac.httparchive.org/en/2024/page-weight ↩
