Ecommerce Site Speed

Core Web Vitals defines the three metrics and their thresholds. Page Speed Optimisation covers the fixes that apply to any site. This article covers what is different about stores: which platforms pass and why, the failure modes that only appear on a storefront, and how to measure a catalogue where the important pages are templates rather than individual URLs.

Why is ecommerce site speed different?

Three things separate a store from a content site.

The failures compound down a funnel. HTTP Archive’s 2025 ecommerce analysis puts it directly: “Ecommerce sites are unusually sensitive to performance because every extra second compounds: slower category pages reduce product views; slower product pages reduce add-to-carts; slower checkout flows reduce conversion.”¹ A slow article loses a reader. A slow store loses a percentage at each of four steps.

Third parties are installed, not written. On a content site, the third-party scripts are the ones a developer added. On a store, apps and plugins inject code into every template by design: reviews widgets, personalisation, live chat, upsell blocks, A/B testing, loyalty programmes, cookie banners, currency switchers. Each was installed by a merchant to solve a commercial problem, and none of them is owned by whoever is now trying to fix LCP.

The unit of measurement is the template. A store has a handful of templates rendering thousands of URLs. Field data is collected per URL and reported per origin, so a store’s Core Web Vitals report can look acceptable while the product template, which generates most of the revenue, fails on its own.

Which ecommerce platforms pass Core Web Vitals?

The platform is the largest single predictor. HTTP Archive’s Web Almanac, using Chrome User Experience Report data from its July 2025 crawl, measured pass rates by platform.¹

Platform (mobile)	Good LCP	Good INP	Good CLS	Passing all three
Shopify	86%	90%	92%	76%
Squarespace Commerce	76%	96%	89%	69%
Wix eCommerce	76%	85%	95%	66%
PrestaShop	65%	89%	81%	50%
WooCommerce	39%	88%	85%	35%

Magento sits at 35% on mobile and 36% on desktop.¹ For comparison, 48% of all mobile origins and 56% of all desktop origins passed all three in the same dataset.² Shopify is well above the web as a whole; WooCommerce and Magento are below it.

Two things stand out in the metric-level numbers. LCP is what separates the platforms: 86% good for Shopify against 39% for WooCommerce, while CLS and INP are within 10 points of each other. And INP falls off on mobile in a way it does not on desktop, where almost every platform sits at 99%. Interactivity problems on stores are mobile problems.

The Almanac attributes the pattern to control rather than to the software itself, concluding that “tighter platform control can correlate with better median outcomes, but the gap is not destiny”, and that “self-hosted and heavily customized stacks can perform well when engineering discipline is strong”.¹ A hosted platform sets the hosting, the CDN, the image pipeline and the theme review standard. A self-hosted store inherits whatever hosting, theme and plugin set the merchant chose. The gap is a distribution of decisions, not a ceiling: a well-built WooCommerce store outperforms a badly built Shopify one.

Shopify’s own analysis of actively selling stores reports “nearly 80% of Shopify stores pass all Core Web Vitals thresholds”, close to the Almanac’s 76%.³ Both draw on Chrome User Experience Report data at different dates rather than measuring independently, so the agreement confirms the figure is stable, not that two methods converged on it.

The practical reading for a merchant on a hosted platform is that passing is the norm rather than an advantage. The practical reading on WooCommerce or Magento is that the platform median is a poor benchmark, because roughly two thirds of comparable stores are failing.

What actually slows an online store down?

The generic causes still apply, and are covered in page speed optimisation. These are the ones that appear specifically on storefronts.

Apps and plugins injected into every template. Most add JavaScript to every page whether or not the page uses the feature. A reviews widget belongs on the product template; it commonly loads on the basket and the homepage too. Auditing what each installed app costs, and where it loads, is usually the largest available saving on an established store.

Product galleries competing with the LCP element. A product page often loads six to twelve images plus a zoom library, and the gallery script frequently defers the main product image behind its own initialisation. Across the web, roughly 17% of pages lazy-load their LCP image and only 17% of mobile pages with an LCP image set fetchpriority="high".² On product templates, the gallery is a common cause of both.

Variant switching. Changing a size or colour on a product page usually triggers a JavaScript update to price, availability, images and the add-to-cart state. Where this re-renders more than it needs to, or refetches variant data on every interaction, it registers as poor INP on exactly the interaction that precedes a purchase. Shopify’s theme documentation names variant overfetching as a specific recommendation, though it files it as a server-render cost affecting TTFB: iterating all variants forces expensive database queries.⁴

Mega menus. A navigation menu listing every category and sub-category ships that markup in the initial HTML on every page. Shopify’s documentation treats mega menu DOM overhead as its own recommendation.⁴ The cost is paid on every template.

Faceted navigation reflow. Applying a filter that replaces the product grid without reserving its space produces layout shift on the template where users spend the most time comparing. Faceted navigation covers the crawling and indexing side of filters; the rendering side is a CLS problem.

Server response time on self-hosted stores. Category pages that run product queries, stock lookups and price calculations per request produce high TTFB before any front-end work matters. This is the most likely explanation for the LCP gap between hosted and self-hosted platforms.

How much does site speed affect ecommerce conversion?

Shopify published an analysis of its own stores in April 2026, bucketing actively selling stores by measured performance over a 28-day period at the turn of January and February 2026 and comparing median conversion rates between buckets.³ It reports:

• “for every 100 milliseconds slower a store loads, conversion tends to be about 3.5% lower”
• “stores with 2.5 second LCP report roughly 30% lower conversion than stores with 1.5 second LCP”
• “For every 32 milliseconds slower a store responds to interactions, conversion tends to drop by about 1.5%”

Two qualifications belong with those numbers. It compares different stores against each other rather than testing one store before and after a change, so it establishes that faster stores convert better rather than that a given store will gain 3.5% by finding 100 milliseconds. Shopify’s own phrasing, “tends to be”, reflects that. And it is Shopify’s data about Shopify stores, which are already the fastest platform cohort in the Almanac figures.

The effect size is not uniform across those stores either. Shopify reports that mature, higher-volume stores see roughly a third of the effect that smaller stores do, so 3.5% describes the population rather than any particular merchant.³

The ranking side is smaller and better documented. Google states that “Core Web Vitals are used by our ranking systems”, and in the same document that there is no single page experience signal, that good scores do not guarantee ranking, and that “trying to get a perfect score just for SEO reasons may not be the best use of your time”.⁵ For a store, the conversion case is the stronger one, and it does not depend on how Google weights the metrics.

How should you measure store performance?

Field data decides, lab data diagnoses. Google states that Core Web Vitals are used by its ranking systems, but has not published the measurement window those systems use.⁶ What is documented is the Core Web Vitals report in Search Console, which draws on Chrome User Experience Report field data over the last 28 days.⁷ Lighthouse and PageSpeed Insights lab runs are for finding the cause once the field data has identified a problem.

Measure per template. Test a representative URL from each of the homepage, a collection or category page, a product page, the basket and search results. An origin-level pass can conceal a failing product template, and the product template is the one attached to revenue.

Test the deep pages, not the flagship ones. The top-selling product page is often the one that has had attention. A product buried at depth four with fifteen variants and a full reviews block is the more representative test.

Test on a real mid-range phone. The INP figures above show mobile as the weak axis for every ecommerce platform. Desktop testing hides variant switching, gallery and menu problems almost completely.

Check field data segmented by device. A store passing overall while failing on mobile is a common pattern, and mobile is usually the larger share of sessions.

Speed optimisation apps that fake the score

Shopify’s theme performance documentation names a practice worth checking for before trusting any store’s score. Some “speed optimization” services “cheat performance testing tools by detecting when those tools are running and serving altered pages that score well but provide no real benefit”, identifying the tool “by fingerprinting the client at the top of the document, before anything else runs”.⁸

These are two separate techniques and they fail differently. Under testing tool detection, the app serves an altered page only to the tool, so “the numbers you’re shown describe a page that no shopper ever receives”. Under LCP hijacking, the script injects “an element that paints almost immediately and covers the viewport”, so “the reported LCP drops because the metric now describes a different element”. That element is served to everyone, which is what makes this variant harder to catch.⁸

The underlying point applies whether or not an app is involved: “Core Web Vitals are proxies for the experience, not the experience itself. A proxy can be satisfied without the thing it stands for improving at all.”⁸

Comparing lab against field only catches the first variant. Under LCP hijacking the injected element is served to real users too, so, in Shopify’s words, “field data and lab data agree, which makes the manipulation look like a genuine win”.⁸

The checks that do work are the ones Shopify gives. Read the Largest Contentful Paint element in the diagnostics and see whether it is the element a shopper would call the main content, or something artificial. Scrub the filmstrip to the LCP timestamp and compare it against the frame where the hero image actually appears. And search the loaded sources for tool fingerprints such as Chrome-Lighthouse, Moto G or navigator.platform. The general rule is to verify a change against what the user sees and does rather than against the score alone.⁸

Do Core Web Vitals affect AI shopping visibility?

Not directly, and treating store performance and AI visibility as one problem leads to the wrong work. AI retrieval crawlers fetch raw HTML and do not execute JavaScript, so LCP, INP and CLS, which all describe a rendered page in a real browser, are not measured on that path at all. A product template can pass all three and still be invisible to every AI shopping surface if its price, variants and description are injected client-side.

One metric serves both audiences: TTFB. It is the first component of LCP for a shopper, and it is most of what a retrieval crawler experiences. Where the two diverge, the fix for AI visibility is server-rendered product data rather than anything in the Core Web Vitals toolkit. The crawler behaviour is covered in JavaScript SEO.

What to fix first on a store

The order below reflects where the measured failures cluster rather than how difficult each fix is.

1. Audit installed apps and plugins. List what each one loads, on which templates, and what it earns. Removing or scoping an app to the templates that need it is usually the largest single saving and requires no code.
2. Fix the LCP element on the product and collection templates. Confirm the main product image is not lazy-loaded, carries fetchpriority="high", and is not held behind gallery initialisation.
3. Reduce server response time if self-hosted. Where field TTFB is high, no amount of front-end work will bring LCP into range.
4. Reserve space for filters, app blocks and banners. Layout shift on the collection template comes from content injected above or into the product grid after first paint.
5. Profile variant switching and menu interactions on a real phone. These are the interactions that set INP, and they are the interactions closest to the purchase.

Shopify merchants have a platform-specific reference for most of this: Shopify’s performance best practices section runs to 68 pages written against Liquid, the Section Rendering API and its image filters.⁴ The equivalent for WooCommerce is hosting and plugin discipline, which is where its LCP distribution suggests the problem sits.

Footnotes

1. Ecommerce — The 2025 Web Almanac by HTTP Archive ↩ ↩² ↩³ ↩⁴

2. Performance — The 2025 Web Almanac by HTTP Archive ↩ ↩²

3. How store speed affects conversion — Shopify ↩ ↩² ↩³

4. Performance best practices for Shopify themes — Shopify ↩ ↩² ↩³

5. Understanding page experience in Google Search results — Google Search Central ↩

6. Understanding Core Web Vitals and Google search results — Google Search Central ↩

7. Core Web Vitals report — Search Console Help ↩

8. Identify and remove fake performance apps — Shopify ↩ ↩² ↩³ ↩⁴ ↩⁵