Why is my Shopify store slow? The fixes that actually move Core Web Vitals

Shopify names three causes of a slow store: the theme, your installed apps and third-party code added by hand. Unused app scripts and a late hero image are usually the first fixes. You pass Core Web Vitals when 75% of visits get LCP within 2.5 seconds, INP within 200 ms and CLS of 0.1 or less.

Those thresholds come from Google's Web Vitals guidance and are measured at the 75th percentile of real page loads, separately for mobile and desktop. Google says Core Web Vitals are used by its ranking systems, and your Shopify admin reports the same three numbers from your own visitors. Fix those first, and use lab tests to find out why they fail.

What each metric measures, and what breaks it on Shopify

The good and poor bands are the ones Shopify's web performance report uses. The causes match what Shopify's theme performance guide lists for each metric.

Check real visitors before you change anything

Your Shopify admin already has field data. Go to Online Store > Themes for the performance summary, or Analytics > Reports and search for the LCP, INP and CLS reports. The line charts carry numbered markers for events such as app installs and theme updates, so you can see whether a metric got worse the week an app went in. The data can run up to 36 hours behind, and a store still behind its password page won't have any.

There are page type reports too, and they matter. A store can pass on the home page and fail on product pages, and in Shopify's own speed score product pages carry 40% of the weight and collection pages 43%, against 17% for the home page.

PageSpeed Insights shows the same metrics from Chrome users over the previous 28 days, with a Lighthouse lab run underneath. Use the field numbers to decide what to fix and the lab run to find out why. How to read that lab score, and why it changes every time you run it, is in my Lighthouse guide.

The fixes that move the numbers

I work through these in roughly this order. Shopify's guide rates the first two as high impact, for INP and LCP respectively.

Remove app code you don't need

Shopify's guide calls auditing and removing unused apps, pixels and scripts the highest-impact optimisation for responsiveness. Every script competes for the browser's single main thread, and a busy main thread is what makes taps and clicks feel slow, which is what INP measures. Places to look:

• Apps you no longer use. Some apps add code to your theme that isn't removed when you uninstall them, so check each app's removal steps.
• App embeds you switched on once and forgot. They live in the theme editor under App embeds, and you can turn each one off without uninstalling the app.
• Snippets and script tags that old apps left in layout/theme.liquid and the snippets/ folder.
• Tags in your tag manager for campaigns that ended long ago.

For the widgets you keep, limit where they load. A review widget only needs product pages, and a chat widget can wait for the first scroll or tap.

Get the LCP image loading first

On most Shopify pages the LCP element is the hero banner or the main product image. Four things decide how early it arrives:

• It must not be lazy-loaded. Shopify calls lazy-loading the LCP image one of the most common and damaging anti-patterns in themes. The image_tag filter already loads images in the first three sections eagerly, so when a hero is lazy-loaded the cause is usually custom code or a lazy-load library.
• It should carry fetchpriority="high", on that one image only.
• It should be an <img> in the HTML, not a CSS background image, so the browser finds it while it is still reading the HTML.
• If the theme has separate mobile and desktop hero images switched with CSS, phones download both. A <picture> element downloads only the one that matches the screen.

Defer the JavaScript the first screen doesn't need

Add defer to scripts that aren't needed for the first paint, and load heavy widgets when someone actually uses them. Two less obvious costs: A/B testing tools typically inject blocking JavaScript that delays rendering for every visitor, even when the test runs on a handful of pages, and themes that build separate mobile and desktop menus double the size of the DOM, which Shopify links to slower INP.

Stop the page from jumping

image_tag writes width and height on every image, which reserves the space before the file arrives. Hand-written <img> tags in custom sections need them added by hand, so check those first. Content that apps inject after load needs a reserved space, such as a min-height on the app block. Web fonts cause shifts when they swap in at a different size from the fallback font, which Shopify suggests fixing with size-adjust and the font metric overrides.

Serve fonts from Shopify, and fewer of them

Shopify recommends uploading web fonts to its own CDN instead of loading them from Google Fonts or another service, which saves the browser a connection to another domain before text can paint. Every weight you load is another file, so drop the ones the design doesn't use.

Look at the Liquid when the server is slow

If the HTML itself takes a long time to arrive, most of that wait is Liquid rendering on Shopify's servers. Nested loops over products and variants, and metafield lookups inside loops, are the common causes. The Shopify Theme Inspector for Chrome shows how long each section, snippet and filter takes, so you can see which part is slow.

What this looked like in my own work

The Louise Carter flagship shows more than 47,000 customer reviews on its product pages. A review widget that size usually holds up the whole product page while it loads, so I changed the load order: the product renders first and the reviews follow. With every review still on the page, the flagship scored 98 for Lighthouse performance and fully loaded in under 2 seconds, and all five of the brand's stores held at 90+. The Louise Carter case study has the details.

On the previous version of this site, Google Fonts held up the first paint for about a second on mobile until I self-hosted them, one of the changes in the portfolio case study.

When the JavaScript bundle is the problem, apps are the usual cause; which apps slow your store covers what to keep and what to cut.

Fixes that won't move your numbers

Third-party scanners often recommend a CDN, server caching or compression. Shopify already serves stores through a Cloudflare CDN with compression, minification and one-year browser caching on assets, as its help centre explains, so those suggestions don't apply to you.

Be wary of anything that promises a perfect score. Shopify describes speed services that detect Lighthouse and serve it a stripped-down page, or inject an invisible full-screen element so the test reports a fast LCP while shoppers get the same slow page. Shopify's own help says there's no such thing as a perfect speed score, and Google says chasing one just for SEO may not be the best use of your time.

When you don't need a developer

If Shopify's report shows Good for LCP, INP and CLS on mobile, the store is fine and the money is better spent elsewhere. If it doesn't, there is plenty you can do before you hire anyone:

• Uninstall apps you don't use, following each app's removal steps.
• Turn off app embeds you don't need in the theme editor.
• Delete old tags from your tag manager.
• Update to the latest version of your theme. The theme matters: in Shopify's theme performance data for early November 2026, 92.1% of stores on recent versions of Dawn passed all three Core Web Vitals, against 26.7% on the weakest theme in the table.
• Cut the number of sections on long templates and turn on pagination for big collections, both suggestions from Shopify's help centre.

Bring in a developer when the cause sits in theme code: a lazy-loaded hero, scripts blocking the <head>, snippets left by old apps or slow Liquid loops.

To have me find the cause and fix it, see the process and the starting price on my Shopify speed optimisation page.