The thresholds Shopify publishes itself: CLS 0.1, INP 200ms, Lighthouse 60 for the Theme Store. The five highest-impact fixes, how apps affect the score, and lab versus field data.
Your Shopify store's speed directly affects conversion, repeat business and search rankings. This article covers the thresholds Shopify itself publishes, the five technical fixes with the largest impact, how apps affect speed, and the difference between lab and field measurement.
Speed discussions usually collapse into a single number: "what's my Lighthouse score?" Yet Shopify publishes concrete thresholds on both the theme and app side, and real improvement comes from targeting those. The figures below are from Shopify's own developer documentation.
Which thresholds you are aiming at
| Metric | Threshold | Where it comes from |
|---|---|---|
| CLS (layout shift) | 0.1 or less | Built for Shopify requirement |
| INP (interaction delay) | 200 ms or less | Built for Shopify requirement |
| Lighthouse performance score | Average of at least 60 | Shopify Theme Store acceptance |
| An app's impact on the score | No more than −10 points | App store requirement |
The Theme Store threshold is a useful reference: to be accepted, a theme must score at least 60 in Lighthouse averaged across the home, product and collection pages. So if your store is below 60, the problem is probably not the theme itself but what was added to it afterwards.
The five fixes with the largest impact
Shopify's "check these before anything else" list covers the items with the broadest effect on Core Web Vitals:
- Never lazy-load the LCP image. Putting
loading="lazy"on the large above-the-fold image delays it until layout completes. Images visible in the initial viewport should always load eagerly. - Mark the LCP image with
fetchpriority="high". It tells the browser to fetch that image before other resources — a one-line change with measurable LCP improvement. - Don't hide the LCP image behind animations. Fade-in and reveal animations delay the LCP event even after the image has finished downloading.
- Render essential content in Liquid and HTML, not JavaScript. Moving product info, hero content or navigation into client-side JavaScript delays LCP and harms SEO. Liquid renders server-side, before the browser does anything.
- Avoid deeply nested Liquid loops. Loops nested across products, variants and options grow quadratically with catalogue size. A theme that is fast on 10 products can be slow on 100 — the most common cause of high TTFB.
One warning about preload: overusing resource hints competes with the browser's own prioritisation and can make pages slower. Reserve it for the one or two resources the browser discovers late.
Apps: the most commonly overlooked cause of slowness
Shopify measures an app's effect on store speed by comparing the Lighthouse score before and after installation, weighted like this:
| Page | Weight |
|---|---|
| Collection page | 43% |
| Product detail page | 40% |
| Home page | 17% |
The weighting alone is instructive: home page speed is secondary to product and collection pages. Most store owners optimise the home page and leave the pages where conversion actually happens untouched.
The rule: an app must not reduce the storefront Lighthouse score by more than ten points. The practical approach is to remove installed apps one at a time and measure — in most stores two or three apps account for the bulk of the slowdown.
There is also a warning about "fake performance apps": apps that cheat Lighthouse and PageSpeed tests by injecting transparent elements or serving different pages to crawlers. They raise the score without changing the real user experience.
Lighthouse or real user data
The two answer different questions, and confusing them is the most common measurement mistake:
| Field data (RUM) | Lab data (Lighthouse) |
|---|---|
| Shows what real users experience | For debugging a specific issue |
| For before/after comparison | Repeatable, comparable measurement |
| For deciding what to optimise | For automated checks in CI/CD |
| Insufficient on new or low-traffic stores | The only option when field data is missing |
Lighthouse scores can differ significantly from field data — lab tests run on a single device with simulated throttling, while your real users span a wide range of devices, connections and locations. Always validate a lab improvement against field data.
Mobile: where the real test happens
Core Web Vitals are measured on mobile by default, and the majority of Shopify traffic is mobile. In other words, mobile performance is theme performance. The mobile-specific items:
- Test with realistic throttling. A test without mobile CPU and network constraints is misleading.
- Remove intrusive interstitials. Full-screen overlays that cover content on load bring both a Google penalty and a CWV loss.
- Increase tap target size. Interactive elements should be at least 48 × 48 px on mobile; small targets produce mis-taps and INP damage.
- Fix content wider than the viewport. Horizontal scrolling harms CLS.
- Keep content parity between mobile and desktop. Content hidden on mobile with CSS can be deprioritised by Google's mobile-first indexer.
Measurement and sustainability
Shopify's official linter, Theme Check, catches performance violations such as oversized bundles, parser-blocking scripts and remote assets before deployment. Putting it in the development flow stops problems before they reach production.
Why do one-time performance projects fail? Because every new app, every new section and every campaign script pulls the score back down. What works is binding measurement and review into a repeatable cycle — making a measurement standard after every theme update or app installation.
Common mistakes
- Optimising only the home page. 83% of the measurement comes from product and collection pages.
- Treating the Lighthouse score as the whole truth. An improvement not validated in field data is not an improvement.
- Never reviewing apps. Unused apps keep loading their scripts until they are removed.
- Revealing the hero image with an animation. The aesthetic gain is paid for in LCP.
- Not re-measuring as the catalogue grows. Nested Liquid loops are invisible on a small catalogue and wreck TTFB on a large one.
Conclusion
Speed optimisation on Shopify is not a vague "improvement" exercise; it is engineering work against thresholds Shopify publishes itself. Loading the LCP image correctly, rendering critical content in Liquid, and keeping the app inventory clean deliver most of the gain in the majority of stores.
To measure the effect of speed on conversion, see our article on conversion rate; for the measurement setup itself, see GA4 e-commerce tracking.
At Commerslab we audit Shopify theme and app performance against these thresholds. See our Shopify store setup service or request a speed audit for your store.
