Shopify Page Speed Optimisation: The 8 Levers That Actually Move Core Web Vitals

What Shopify does well on page speed

It's worth saying plainly, because most Shopify SEO content doesn't: the platform's baseline speed is good. Shopify ships a global CDN with HTTP/2 by default and HTTP/3 in most regions, HTTPS on every store with no configuration required, an image CDN that automatically serves WebP via the ?format=webp parameter, and mobile-first responsive themes out of the box. None of this is something a Shopify merchant has to build or maintain.

On a stock Dawn theme with no apps installed and default product imagery, LCP typically lands between 1.6 and 2.0 seconds on a throttled 4G connection - comfortably inside Google's 2.5-second "good" threshold, and INP sits in the 80-120ms range with no third-party scripts competing for the main thread. CLS is close to zero because Dawn reserves image dimensions correctly and doesn't inject late-loading banners above the fold.

Compare that to the median WordPress or bespoke React storefront, where CDN configuration, image optimisation, and HTTP/2 support are all things a development team has to actively set up and maintain. Shopify gives you all three for free on day one. This is why, as we've argued before in the complete Shopify SEO guide, most of the "Shopify is bad for SEO" narrative doesn't survive contact with a clean install.

The baseline, in other words, is fine. Genuinely fine. The problem - and it is a large, measurable, entirely self-inflicted problem - is what merchants and their agencies add on top of that baseline once the store goes live.

Why most Shopify stores are slow (spoiler: it's the apps)

We removed four SEO-branded apps from AB Ellie's stack in month one of the engagement. LCP dropped 0.8 seconds before we made a single theme change. Nobody touched a template, an image, or a line of Liquid. We simply deleted apps the store no longer needed and watched the number move. That's the pattern we see repeatedly across client audits: the single largest, cheapest, fastest lever available to almost every Shopify merchant is not a code change at all - it's an app audit.

Here's the mechanism. Every app a merchant installs, even a well-built one, injects at least one script tag into the storefront. That script has to be downloaded, parsed, and executed, and most apps don't defer this work until after the first paint - they run it eagerly so their widget, tracking pixel, or review carousel is ready as early as possible. Individually, this typically costs 50-200 milliseconds of load time. It sounds trivial. It compounds badly.

The average Shopify store in our sample runs between six and twelve apps at any given time - reviews, upsells, page builders, search replacement, subscriptions, chat, and at least one "SEO" app that duplicates functionality Shopify already provides natively. Six installed apps at the low end of that per-app cost still produces an average LCP hit of roughly 700 milliseconds. That is, on its own, frequently the entire difference between a "good" and a "needs improvement" Core Web Vitals verdict from Google - and it happens before anyone looks at theme code, image sizes, or font loading.

Second most common cause, well behind apps but still material: heavy theme customisation. Merchants (or the agencies building their storefronts) add multiple font families for brand reasons, stack complex homepage sections with parallax and video backgrounds, and rarely revisit the customisations once launched. Third: unoptimised images, particularly hero banners exported at full camera resolution and uploaded without resizing.

Here's the contrarian point that gets missed constantly in Shopify speed advice: "switch to a lighter theme" is usually the wrong first recommendation. Theme choice matters, but it matters far less than the app stack sitting on top of it. We've audited stores on Dawn with LCP over 4 seconds because of nine apps, and stores on customised legacy themes with LCP under 2 seconds because the merchant kept their app count to three. Audit apps first, theme second, images third. Doing it in the wrong order wastes weeks rebuilding a theme that was never the bottleneck.

The 8 levers ranked by impact-per-hour

Impact alone is a misleading ranking metric - a full theme rebuild has high impact but takes weeks. What actually matters for prioritisation is impact-per-hour of work. Ranked in that order, based on measured deltas from 12 client engagements:

Lever 2 is the one most teams skip because it sounds like a theme-development task rather than a speed fix. It isn't - it's a 20-minute Liquid change. Here is the exact snippet, compatible with both Dawn and Sense:

{% if template == 'index' %}
  {%- assign hero = section.settings.hero_image -%}
  {% if hero %}
    <link rel="preload" as="image"
      href="{{ hero | image_url: width: 1600, format: 'webp' }}"
      imagesrcset="{{ hero | image_url: width: 800, format: 'webp' }} 800w,
                   {{ hero | image_url: width: 1600, format: 'webp' }} 1600w"
      imagesizes="100vw">
  {% endif %}
{% endif %}

Drop this into theme.liquid's <head>, guarded by the correct template condition for your homepage or PDP hero section. It tells the browser to start fetching the hero image before it has finished parsing the rest of the document - which is precisely what LCP measures.

Core Web Vitals impact calculator

Enter your store's current numbers below. The calculator applies the median measured impact of levers 1 through 8 from our 12-store dataset and gives you an estimated achievable LCP - not a guarantee, but a realistic planning figure based on what we've actually measured elsewhere.

App-by-app performance ranking (bench-tested)

Measured, not estimated, across 12 Shopify client stores. LCP and INP deltas are the median additional contribution each app makes when installed and active on a Product template, holding all other variables constant. Sort by any column to find your priority order.

A pattern worth noting: the apps with the worst CWV cost (Vitals, Growave, Yotpo) are rarely the apps merchants think to question, because their value proposition is bundled marketing rather than a single visible feature. The apps with the best cost-to-value ratio (Judge.me, Klaviyo, ShipStation) tend to do one thing well and load conservatively. When in doubt, prefer narrow, well-built apps over "all-in-one" bundles - bundles almost always cost more in CWV than the sum of their individual features would.

12-store before/after data

This is the underlying dataset the calculator and lever rankings above are built from - anonymised LCP figures across the 12 client stores we bench-tested before and after applying levers 1 through 7 (lever 8, the theme rebuild, was out of scope for most of these engagements).

Common mistakes that make Shopify slow

Five mistakes we see repeatedly across audits, roughly in order of how often they appear:

1. Loading Google Fonts synchronously from fonts.googleapis.com instead of self-hosting the woff2 files. This adds a render-blocking third-party DNS lookup and connection on every single page load, for a resource that could be preloaded from your own CDN.
2. Uncompressed hero images at 3000px or wider, uploaded straight from a camera or design file with no size hints and no responsive srcset. Shopify's CDN can resize on the fly, but only if the theme requests a sensible size - many themes request the original.
3. Chat widgets loaded on every page on first paint instead of after a 3-second idle delay or on user interaction. Nobody opens live chat in the first second of a page load; there is no reason for the script to compete with the hero image for bandwidth.
4. Multiple analytics platforms firing simultaneously on page load - GA4, Meta Pixel, TikTok Pixel, Klaviyo, and Hotjar all initialising in the same render cycle. Each one is individually small, but five of them firing together is a meaningful INP hit, particularly on lower-powered mobile devices.
5. Third-party review widgets rendered above the fold, synchronously, blocking the main thread while star ratings and review counts are fetched from an external API before the rest of the page is interactive.

How to measure Shopify page speed properly

Reconcile four sources, because each answers a different question and none of them alone tells the full story:

• PageSpeed Insights - combines lab data (a single simulated run) with field data (real Chrome User Experience Report data, when available). Use the field data tab, not the lab score, as your primary reference point.
• Chrome DevTools Performance panel - your root-cause tool. Record a trace, find the long tasks, and identify exactly which script is blocking the main thread or delaying the LCP element.
• WebPageTest - for multi-run, geo-specific testing. Run from a UK test location on a throttled connection profile matching your actual customer base, and run at least three times to filter out noise.
• Google Search Console's Core Web Vitals report - real-user data aggregated over a rolling 28-day window. This is what Google actually uses for ranking signals, and it is the slowest of the four to reflect a change.

Field data from PSI and GSC is the truth; lab data from DevTools and WebPageTest is the debugger you use to find and fix the cause. Don't celebrate a lab-score win the day you ship a fix - field data typically takes four to six weeks to catch up, because it's a rolling average of real visitor sessions, not a single synthetic run. Our own technical audits, run through our technical SEO service, always report both lab and field numbers side by side for exactly this reason - and we cross-reference against the wider Shopify SEO guide before recommending a fix priority, alongside our notes on canonical tag hygiene and image SEO fundamentals, since speed and crawl efficiency are frequently solved by the same underlying app audit.

Frequently asked questions