Shopify Core Web Vitals — LCP, CLS and INP for Shopify stores

Core Web Vitals thresholds and what they mean for ranking

Google uses three threshold bands for each CWV metric. Understanding where your store sits — and by how much — determines how much effort is worth investing.

Largest Contentful Paint (LCP): Good = under 2.5 seconds. Needs Improvement = 2.5s–4.0s. Poor = over 4.0 seconds. LCP measures how quickly the largest visible content element (usually an image or heading) loads. For Shopify, this is almost always an image.

Cumulative Layout Shift (CLS): Good = under 0.1. Needs Improvement = 0.1–0.25. Poor = over 0.25. CLS measures unexpected layout shifts — content jumping around as the page loads. Even a score of 0.12 (just above the “good” threshold) represents noticeable visual instability that hurts both user experience and ranking signals.

Interaction to Next Paint (INP): Good = under 200ms. Needs Improvement = 200ms–500ms. Poor = over 500ms. INP replaced FID in March 2024. It measures how quickly the page responds to any user interaction — a click, a tap, pressing a key. INP failures are the most common CWV issue on app-heavy Shopify stores.

A store in the “needs improvement” band for any metric is not penalised the same way a “poor” store is. The ranking impact of CWV is graduated — moving from poor to needs improvement matters, and moving from needs improvement to good matters more. Moving a store from LCP 3.8s to 2.3s will have a more measurable ranking impact than moving from 2.7s to 2.3s.

How to read the Google Search Console Core Web Vitals report

The GSC Core Web Vitals report is under Experience > Core Web Vitals. It shows two tabs: mobile and desktop. Always focus on mobile first — that’s where Shopify stores most commonly fail, and Google’s mobile-first indexing means mobile CWV is the primary ranking signal.

The report groups URLs into clusters rather than showing individual URL scores. A “poor” URL group means multiple URLs with similar page templates are all failing. When you see “Product pages — 47 poor URLs”, it means your product page template has a systemic CWV failure that affects all product pages.

Field data in GSC is drawn from the Chrome User Experience Report (CrUX) — real measurements from Chrome users visiting your store over the previous 28 days. This is the data Google uses for ranking. To see individual URL scores, click into a URL group and then “Open in URL Inspection” or use PageSpeed Insights to test specific URLs.

GSC CWV data lags about 28 days. After making fixes, wait four weeks before expecting the GSC report to reflect improvements. PageSpeed Insights and Lighthouse give immediate feedback on lab score improvements, but the field data takes time.

LCP: the fetchpriority fix for Shopify Dawn theme

The most impactful single LCP fix for most Shopify stores is telling the browser to load the hero image at highest priority. By default, browsers don’t know which image is the LCP element until they’ve parsed the page. Adding fetchpriority="high" tells the browser to start loading this image immediately, before other resources.

In Dawn theme, the hero image is rendered in sections/image-banner.liquid. The image tag typically looks like this:

{%- assign hero_image = section.settings.image -%}
{{ hero_image | image_url: width: 1920 | image_tag:
  loading: 'lazy',
  class: 'banner__image',
  widths: '375, 550, 750, 1100, 1500, 1780, 2000',
  sizes: '100vw'
}}

The fix is to change loading: 'lazy' to loading: 'eager' and add fetchpriority: 'high':

{{ hero_image | image_url: width: 1920 | image_tag:
  loading: 'eager',
  fetchpriority: 'high',
  class: 'banner__image',
  widths: '375, 550, 750, 1100, 1500, 1780, 2000',
  sizes: '100vw'
}}

This change alone commonly improves LCP by 0.3–0.8 seconds. Apply the same fix to the first product image on product page templates (sections/main-product.liquid in Dawn) and to collection banner images.

Additionally, ensure the LCP image is not hidden behind JavaScript-rendered content. If a slider or carousel loads the hero image via JavaScript, the browser cannot preload it — the image doesn’t appear in the HTML source. Convert hero images to native HTML <img> elements rather than JS-injected backgrounds.

CLS: the image width/height fix

Every <img> element without explicit width and height attributes causes layout shift when it loads. The browser allocates zero space for the image, renders surrounding content, then shifts everything when the image dimensions are known. This is the most common source of CLS on Shopify stores.

The fix in Liquid:

{{ product.featured_image | image_url: width: 800 | image_tag:
  width: 800,
  height: product.featured_image.height | times: 800 | divided_by: product.featured_image.width,
  loading: 'lazy',
  alt: product.featured_image.alt
}}

Or, using Shopify’s image_tag filter which handles width/height automatically in recent versions of Dawn:

{{ product.featured_image | image_url: width: 800 | image_tag: widths: '400, 800, 1200' }}

Dawn 8.0+ includes width/height attributes by default. If you’re on an older version of Dawn or a custom theme, audit all image tags in the theme for missing width and height attributes.

For web fonts, prevent CLS caused by font swap by adding font-display: optional to your @font-face declarations. This tells the browser not to render a fallback font — it waits briefly for the web font, then falls back permanently, eliminating the swap shift.

INP: diagnosing with Chrome DevTools Performance panel

INP failures on Shopify stores almost always trace to long tasks — JavaScript execution blocking the main thread and preventing the browser from responding to user input.

To diagnose with Chrome DevTools:

1. Open Chrome DevTools (F12), go to the Performance panel.
2. Enable “Web Vitals” in the recording settings.
3. Start recording and interact with the page — click buttons, scroll, interact with the add-to-cart button.
4. Stop recording and examine the timeline.
5. Long tasks appear as red-flagged bars above 50ms. Click a long task to see which script is responsible.

Common Shopify INP causes identified this way: Klaviyo email capture scripts executing on page load; chat widget initialisation scripts (Gorgias, Tidio) blocking the main thread for 200-400ms; review app widgets (Yotpo) loading their full widget bundle synchronously; analytics scripts (GA4 + Meta Pixel + TikTok Pixel combined) creating cumulative blocking time over 600ms.

The fix is almost always deferring third-party scripts. Use defer or async attributes on script tags, or move scripts to load after the first user interaction using an Intersection Observer or a “facade” pattern.

App audit: which categories cause which CWV failures

Understanding which app categories create which CWV problems allows you to prioritise removal or replacement.

Chat widgets (Gorgias, Tidio, LiveChat, Intercom): Primary CWV impact: INP. Chat widgets inject large JS bundles (50-150kb) that compete with the main thread. Secondary impact: CLS if the chat bubble position isn’t reserved. Fix: use a facade — show a static chat button that loads the full widget only when clicked.

Review apps (Yotpo, Judge.me, Okendo, Stamped): Primary CWV impact: LCP if widget is placed above-fold on product pages. Secondary impact: INP (widget JS competes with main thread). Fix: ensure review widgets are loaded below-fold; use lazy loading for widget JS.

Popup and email capture apps (Klaviyo popups, Privy, Omnisend): Primary CWV impact: CLS when popups inject content that shifts layout. Secondary impact: INP. Fix: use exit-intent triggers rather than time-based triggers to defer script execution; ensure popups use position: fixed rather than pushing content.

Page builders (PageFly, GemPages, Shogun): Primary CWV impact: LCP (additional render layers). Secondary impact: CLS (rendered content without reserved dimensions). Fix: if using a page builder for the homepage or key landing pages, measure CWV before and after and weigh the conversion benefits against the performance cost.

Multiple analytics scripts: Individual analytics scripts (GA4, Meta Pixel, TikTok Pixel, Pinterest Tag) each add 30-80ms of blocking time. Combined, they can add 200-400ms of Total Blocking Time, directly impacting INP. Fix: use Google Tag Manager to manage all scripts in a single container and defer firing until user interaction.

Priority fix list ordered by typical impact

The following order reflects which fixes produce the largest CWV improvements on typical Shopify stores:

1. Add fetchpriority=“high” and loading=“eager” to LCP image — affects LCP directly; 15-minute fix.
2. Add width and height to all image tags — fixes CLS across all page types; requires theme audit.
3. Defer or lazy-load chat widget — typically recovers 100-200ms of INP.
4. Convert hero image from JS-rendered to native HTML — required if using a slider for the hero.
5. Add font-display: optional to web fonts — eliminates font-swap CLS.
6. Audit and consolidate analytics scripts via GTM — reduces total blocking time.
7. Remove or replace high-impact apps — run CWV test before and after each removal.
8. Inline critical CSS — prevents render-blocking stylesheets from delaying LCP.
9. Enable WebP serving for product images — reduces image payload, improves LCP on slow connections.
10. Move non-critical scripts to body end — reduces render-blocking resource count.

What NOT to do: paid fixes that don’t help

Several common paid approaches to CWV improvement provide minimal return:

Image compression apps (Crush.pics, TinyIMG, Imageify): Useful for reducing file size, but Shopify’s native CDN already serves images at appropriate sizes via the image_url filter. If your images are already going through Shopify’s CDN, a third-party compression app adds another JavaScript layer without meaningfully changing CWV scores.

“Speed boost” apps that promise to improve your PageSpeed score: Many of these apps manipulate the Lighthouse test environment rather than improving real-world performance. A score improvement in PageSpeed Insights without a corresponding improvement in GSC field data is a cosmetic fix, not a real one.

Removing all apps blindly: App removal should be data-driven. Remove apps one at a time, measure CWV before and after each removal, and only remove apps where the CWV cost exceeds the business benefit. A chat widget that generates 30% of support resolutions is worth more than 50ms of INP improvement.

Switching to a “faster” theme without fixing root causes: If CWV failures stem from third-party apps, switching themes won’t fix them. Audit app impact first; theme changes second.

How to re-verify after making changes

After making CWV fixes, use PageSpeed Insights for immediate feedback on lab score improvements. Test both mobile and desktop, and test the specific page types you fixed (homepage, product pages, collection pages) — not just the homepage.

For field data verification in GSC, expect a 28-day lag. The CWV report in GSC uses a rolling 28-day window of real user data. A fix deployed today will not fully appear in the GSC report for four weeks. However, if a fix substantially improves scores (e.g., LCP drops from 4.5s to 2.1s), you may see the URL group shift from “poor” to “needs improvement” faster, as more recent data dominates the window.

Use the URL Inspection tool in GSC to check individual URLs — it will show the most recent CrUX data available, which refreshes more frequently than the aggregated CWV report. For newly launched fixes, PageSpeed Insights remains the fastest verification tool. Run it from both mobile and desktop simulation, and run it three to five times to account for server-side variance in the lab test results.