Core Web Vitals for online stores: the thresholds and the usual causes

Core Web Vitals are Google's three measures of how a page feels to real visitors: Largest Contentful Paint (LCP), how fast the main content appears; Interaction to Next Paint (INP), how fast the page responds to taps and clicks; and Cumulative Layout Shift (CLS), how much the layout jumps while loading. Google counts a page as good when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Mobile and desktop are assessed separately, and a pass needs all three. On a store, a slow LCP usually means shoppers waiting for the product image and price, and a poor CLS means buttons moving under their thumbs.

Platform data gives a sense of scale. In the 2025 Web Almanac, 76% of Shopify stores and 35% of WooCommerce stores had good Core Web Vitals on mobile, and LCP was "the biggest differentiator". A separate dataset puts the figures at 81.7% and 38.9%. I found no published figures for Salla or Zid.

How to check

Look at field data first: the Core Web Vitals report in Search Console, or the field-data section of a PageSpeed Insights result. Both draw on Chrome UX Report (CrUX) data from real visits over 28 days.
Expect "no data" on small stores. CrUX only includes pages that are "sufficiently popular", and Google doesn't publish the threshold. No data doesn't mean the store is fast.
Use a lab test (PageSpeed Insights or Lighthouse) to see which element is the LCP and which scripts load first.
List every script and who added it: the platform, the theme, an app or plugin, or your own tags. Only the last three are yours to fix.
Run the free audit. When the audit server has a Google API key configured, Store Audit by Ahmed Fayed reads CrUX field data (page, then site). A store with no field data gets no field-data finding; the report lists that check under "Could not check". The audit also estimates page weight and request count, flags render-blocking third-party scripts, attributes each script to platform, theme, app or your tags, and checks for a lazy-loaded LCP image, old image formats, images without dimensions, missing compression and very large pages. The full crawl adds a lab speed test (PageSpeed Insights, also only with the API key) on the home, product and category templates.

How to fix

Google's LCP guidance applies everywhere: never lazy-load the LCP image, give it fetchpriority="high", and preload it if it's a CSS background image. In a healthy LCP, server response and image download take most of the time, and load and render delays stay under 10% each. Give images a width and height so the page reserves space for them, which prevents layout shift:

<img src="/images/hero.webp" width="1200" height="600" fetchpriority="high" alt="New oud collection">

Salla

Salla's default Raed theme uses native lazy-loading and minified CSS. Scripts the platform injects can't be changed by merchants; what you control is apps, GTM tags, custom code and images. I found no current Core Web Vitals benchmark for Salla stores. The only measured study I found is from 2022 on a legacy theme, so I don't treat its numbers as current. Remove apps and GTM tags you no longer use, and upload images close to the size they're displayed.

Zid

Zid serves product images through Cloudflare image resizing. Its help center warns that everything added in GTM loads on the storefront and that numerous or heavy tags slow pages. Review your GTM container and delete what you don't use.

Shopify

Shopify's CDN serves AVIF or WebP automatically when the theme outputs images through image_url with a width. Images set as CSS backgrounds, hard-coded image URLs and images loaded by apps bypass this. Uninstalled apps can leave snippets and script tags in the theme; find and remove them. Make sure the hero image isn't lazy-loaded.

WordPress/WooCommerce

Since WooCommerce 7.8, the cart-fragments script loads only with the Cart widget or when another script depends on it. Themes or plugins that load it on every page add an uncached request to each page view. Page builders such as Elementor and Divi add DOM and CSS weight; I have no current benchmark for how much. If no page caching is detected, add it through a cache plugin or your host.

Custom-coded

Work on server response time, enable gzip or Brotli compression on HTML, set cache headers on static files, and load third-party scripts in <head> with async or defer.

Common mistakes

Lazy-loading the first product image or the homepage hero.
Judging speed by one lab score instead of field data from real visits.
Uninstalling an app without removing its leftover code.
Adding tags to GTM without removing old ones.
Reading "no field data" as "fast".

Run the free Store Audit by Ahmed Fayed to see what slows your store's pages. If you'd like help fixing this, contact me on WhatsApp +20 102 702 0701 or at ahmed-fayed.com.