Core Web Vitals on Shopify: how to improve them in 2026

Q: What if I have low traffic and no CrUX data?

If the store has <5,000 visits/month, Google uses proxy signals and ranking may not penalise you for "unmeasurable" CWV. In that case, optimise for Lighthouse score and the rest comes with traffic. For a systematic review of the whole theme before scaling, a Shopify technical SEO audit covers CWV alongside everything else.

Q: Does INP affect desktop or only mobile?

INP affects both, but Google has weighted mobile more heavily since 2021 (mobile-first indexing). In practice, optimising INP for mobile usually solves desktop too.

Core Web Vitals are the three performance metrics Google measures on every page and that have factored into its algorithm since 2021. On Shopify, all three are fixable, but most stores leave them in red because they look for the magic app before reviewing what the theme actually loads. This guide explains the levers that work in real accounts.

I’ll cover LCP, INP and CLS separately — what causes each problem on Shopify specifically, and which interventions have the best return per hour invested.

In 30 seconds:

The 3 Core Web Vitals: LCP (<2.5s), INP (<200ms), CLS (<0.1) per web.dev/vitals

INP replaced FID on March 12, 2024 — INP measures real interaction latency, not just the first click

Google uses field data (CrUX), not lab data: PageSpeed Insights shows both

On Shopify the 3 biggest causes are an unoptimised hero image (LCP), apps injecting JS (INP), and fonts without font-display: swap (CLS)

The theme.liquid file and installed apps weigh more than any “speed optimizer” from the App Store

What are Core Web Vitals and why do they matter on Shopify?

Core Web Vitals are three metrics Google measures on real visits through Chrome (CrUX dataset) and has used as a ranking signal since the Page Experience update in 2021. In 2024, Google replaced FID with INP, a stricter metric because it measures the latency of every interaction, not just the first (Google Search Central, 2024).

For Shopify specifically, the problem is that Google evaluates performance in production (with installed apps, tracking scripts, popups), not on a clean preview. A store can have a fast theme locally and a red PageSpeed Insights in production because apps add 1-2 MB of JavaScript after deploy.

When I audit a Shopify store, the first thing I do isn’t open PageSpeed Insights — I open web.dev/measure against the most-visited product page and look at the breakdown by origin for each resource. Third-party apps usually account for 40-70% of total JavaScript. To understand which parts of the theme actually control these metrics in code, I wrote a guide on Shopify Liquid for SEO covering the relevant snippets in theme.liquid.

How do I improve LCP on Shopify?

LCP (Largest Contentful Paint) captures the moment the largest visible element gets painted during page load — usually the hero product image or the homepage banner. Target: below 2.5 seconds at the 75th percentile of mobile visits.

On Shopify, the two highest-ROI levers are: how the LCP image is served, and how much JavaScript blocks rendering before it paints.

Hero image optimisation. Almost every Shopify theme loads the hero image without loading="eager" and without fetchpriority="high". Result: the browser downloads it after non-critical scripts. Changing it in the hero theme snippet usually drops LCP by 0.5-1.5 seconds.

<img
  src="{{ section.settings.hero_image | image_url: width: 1200 }}"
  srcset="{{ section.settings.hero_image | image_url: width: 480 }} 480w,
          {{ section.settings.hero_image | image_url: width: 768 }} 768w,
          {{ section.settings.hero_image | image_url: width: 1200 }} 1200w"
  sizes="100vw"
  width="{{ section.settings.hero_image.width }}"
  height="{{ section.settings.hero_image.height }}"
  loading="eager"
  fetchpriority="high"
  alt="{{ section.settings.hero_alt }}">

Font loading. If your theme loads Google Fonts via <link> without preconnect, the browser waits for the DNS lookup before downloading. Adding <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> in the head saves 100-300 ms of LCP.

Render-blocking apps. Apps like Klaviyo, Privy or free popups often load their JS synchronously. Use Chrome DevTools Coverage to see what % of each app’s JS actually runs before LCP. If usage is <5%, defer is safe. For deeper image optimisation on Shopify, I wrote a dedicated guide on image optimization in Shopify.

How do I reduce INP (the metric that replaced FID)?

INP (Interaction to Next Paint) measures the latency between a user action (click, tap, keystroke) and the next browser paint. Target: below 200 ms at the 75th percentile. INP is stricter than FID because it measures every interaction across a session, not just the first (web.dev INP, 2024).

What makes a Shopify have bad INP? The problem is almost never the theme — it’s what the apps load in the background while the user navigates. Three patterns I see in every audit:

Chat apps (Tidio, Gorgias, Shopify Inbox). They load heavy scripts that run scroll listeners, mutation observers, and process events on the main thread. When the user taps “add to cart”, the browser can’t respond until the app finishes.
Duplicate tracking pixels. Accounts running GA4, Meta Pixel, TikTok Pixel and a custom GTM pixel. Each adds 50-150 ms to the browser’s task queue.
Review and gallery apps. Loox, Judge.me, Yotpo. They build DOM dynamically with hundreds of elements, creating long tasks of 200-400 ms every time the user interacts with the page.

The concrete fix: audit apps with DevTools Performance → record 30 seconds of normal browsing → sort long tasks by origin. Apps with >300 ms of blocking time per session are clear candidates for uninstall or deferred config.

How do I eliminate CLS on Shopify?

CLS (Cumulative Layout Shift) counts every shift in visible content during page load. Target: below 0.1. High CLS happens when an image, font or banner is injected without the browser having reserved space for it.

The most frequent causes on Shopify are three, each with a direct fix:

Images without width and height. If you add images without those attributes, the browser doesn’t know how much space to reserve and reflows when the file arrives. The fix: always use the attributes via Liquid, as in the snippet from the LCP section above. With Shopify, the image.width and image.height properties are native, so there’s no excuse to omit them.

Fonts without font-display: swap. If your theme loads Google Fonts without this property, text initially doesn’t render and then jumps when the font arrives. Check the fonts CSS:

@font-face {
  font-family: 'YourFont';
  src: url('{{ "your-font.woff2" | asset_url }}') format('woff2');
  font-display: swap;
}

Banners and popups that appear late. Cookie apps, discount popups or free-shipping banners that inject after the main content renders generate visible shifts. Two options: reserve space with CSS (a container with min-height even if empty) or load the app before the main content (worse for LCP, better for CLS — you have to choose).

Which Shopify apps tend to break Core Web Vitals?

I’ve audited dozens of Shopify stores and there’s a group of apps that keep showing up as the main causes of bad CWV. It’s not that the apps are bad; their impact on CWV simply accumulates.

Chat apps (Shopify Inbox, Tidio, Gorgias, Re:amaze) add 100-300 KB of JS each, and the widget loads even if the user doesn’t open it. Mitigation: use a delayed trigger to show it only after 5s or 50% scroll. Then there are the review apps (Loox, Judge.me, Yotpo), which load heavy gallery and carousel widgets and typically block INP when the user scrolls through reviews.

Page builders (PageFly, Shogun). They generate dense markup with many nested elements and inline scripts. Can add 500 KB-1 MB of HTML on the homepage alone.
Upsell and popup apps (Privy, Bold, ReConvert). Their JS runs on the main thread during critical events (add to cart, checkout). Usually the main culprits for bad INP.
And the silent trap: additional tracking apps (Triple Whale, Northbeam, Lifesight). Each adds its own pixel on top of the native ones. Typical pattern I see daily: store with 8-12 different pixels running on every pageview, without the owner knowing half of them are still active.

The practical rule: if an app doesn’t generate more than €1,500/month in direct value (attributable sales, qualified leads or quantifiable time savings), it doesn’t justify the performance cost it adds. Audit quarterly — you always find 2-3 forgotten apps still running unused.

How do I measure Core Web Vitals on Shopify reliably?

PageSpeed Insights shows two data types: lab (synthetic test) and field (CrUX, real Chrome user data). Google uses CrUX for ranking, not Lighthouse. The difference matters: a store can score 95/100 in Lighthouse and red in CrUX if real users have slow phones or bad connections.

How do you tell them apart? In PageSpeed Insights:

CrUX data appears at the top as “Discover what your real users are experiencing” — that’s what Google sees.
Lighthouse score appears below — useful for diagnosing issues, not for evaluating ranking.

To access the CrUX dataset directly, Search Console has a Core Web Vitals report that groups URLs by status (Good/Needs improvement/Poor). It’s the same data Google uses, aggregated by similar URL groups.

Three tools I combine in an initial audit:

Tool	What it measures	When to use
PageSpeed Insights	LCP/INP/CLS field + lab	Initial diagnosis of a URL
Search Console Core Web Vitals	Aggregated status by URL groups	Detect which template (product, collection, blog) is worst
Chrome DevTools Performance	Detailed long-task traces	Identify which app or script causes each issue

If your store has >5,000 visits/month, field data (CrUX) will be reliable. Below that, PageSpeed Insights may lack samples and the indicator stays as “Insufficient data”. CWV is one piece of technical SEO — for the full picture, Shopify SEO for ecommerce 2026 covers the rest of the checklist.

Frequently asked questions

Do paid Shopify themes automatically improve Core Web Vitals?

Not automatically. Premium themes like Impulse, Symmetry or Prestige are well built, but real performance depends on installed apps and configuration. I’ve seen stores with €300 themes in worse shape than stores on Dawn (free). The theme sets the baseline; apps determine the final result.

Is it worth paying for a “speed optimizer” app from the Shopify App Store?

Almost never. Most do three things: image lazy loading (which you can do with loading="lazy" in Liquid), preconnect to external domains (1 line in theme.liquid), and minification Shopify already applies. I only recommend apps when there’s a specific problem outside your control (e.g., third-party apps that don’t respect defer).

How does Shopify Markets affect Core Web Vitals?

Shopify Markets adds minimal overhead (geolocation, currency switcher) but typically introduces a small INP impact if the currency switcher runs before paint. The rule: check after activating Markets — CWV can drop 5-10 points if the implementation is aggressive.

How long does it take Google to update Core Web Vitals after I make changes?

CrUX updates with a 28-day data window, so the full effect of a change shows up at 28-30 days. Search Console usually reflects it at 4-6 weeks. PageSpeed Insights shows the most recent data but still with the 28-day window, so changes appear gradually.

What if I have low traffic and no CrUX data?

If the store has <5,000 visits/month, Google uses proxy signals and ranking may not penalise you for “unmeasurable” CWV. In that case, optimise for Lighthouse score and the rest comes with traffic. For a systematic review of the whole theme before scaling, a Shopify technical SEO audit covers CWV alongside everything else.

Does INP affect desktop or only mobile?