Compare 2025 ecommerce site speed benchmarks for Shopify, WooCommerce, and Wix storefronts, then follow a reproducible product-page audit workflow.
Published:
November 11, 2026
Author：
Yi Cui
Published ecommerce benchmark data shows a clear mobile performance spread among detected Shopify, WooCommerce, and Wix ecommerce origins. In HTTP Archive’s 2025 data, 76% of detected Shopify origins and 66% of detected Wix ecommerce origins passed all three Core Web Vitals, compared with 35% of detected WooCommerce origins. That is useful context, not a platform verdict. The source combines origin-level field data with controlled lab audits, and it does not identify product pages, categories, page weight, or image payload by platform. 1 2
The table below is a published mobile storefront benchmark, not a new Branvas test.
HTTP Archive detected ecommerce technologies with Wappalyzer, then reported Core Web Vitals field outcomes by platform and median Lighthouse Performance scores from its lab crawl. 1 2
| Detected ecommerce platform | Mobile origins | Good LCP | Good INP | Good CLS | Passed all CWV | Median Lighthouse Performance |
|---|---|---|---|---|---|---|
| WooCommerce | 995,782 | 39% | 88% | 85% | 35% | 38 |
| Shopify | 567,932 | 86% | 90% | 92% | 76% | 55 |
| Wix ecommerce | 234,055 | 76% | 85% | 95% | 66% | 64 |
Source: HTTP Archive Web Almanac 2025 Ecommerce chapter. The field columns are the shares of detected mobile origins classified as good for each metric. The lab column is a median Lighthouse Performance score, not a Core Web Vitals result. 1
The source’s 2025 methodology ties the lab crawl to July 2025. Its mobile WebPageTest profile used an emulated Moto G4, a 4G connection profile, an 8x CPU slowdown, a 512 by 360 CSS-pixel viewport, and US cloud test locations. Lighthouse was version 12.8.0. 2
The field data is different. The methodology says the 202507 CrUX release represented visits by Chrome users during June 2025, and the tables use origin-level real-user data. 2
The benchmark has an important coverage limit: HTTP Archive crawls a home page plus one largest internal link. That second page may be a product page, but the study does not label it as one. 1 2
It also does not publish the requested platform rows by product category, traffic band, page weight, image payload, or LCP/INP/CLS percentiles. Those are missing data points, not values to estimate.
Core Web Vitals are field metrics. A page or origin is assessed at the 75th percentile of page views, so the target is about the experience of most visits, not a single best-case test. 3
| Metric | What it reflects | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the largest visible content is rendered | 2.5 seconds or less | Over 2.5 to 4 seconds | Over 4 seconds |
| INP | Responsiveness to click, tap, and keyboard interactions | 200 ms or less | Over 200 to 500 ms | Over 500 ms |
| CLS | Unexpected visual movement | 0.1 or less | Over 0.1 to 0.25 | Over 0.25 |
A field assessment passes all Core Web Vitals when the 75th-percentile LCP, INP, and CLS values are all good. If INP is missing but LCP and CLS are good, PageSpeed Insights can still show a pass. If LCP or CLS is missing, it cannot assess the page or origin. 4
Do not equate a Lighthouse Performance score with a field CWV pass. PageSpeed Insights calls 90 or above a good lab Performance score, but a lab run is a simulated page load while field data reflects real visitors over the prior 28 days. 4
No. The published results are observational.
A platform label is mixed with theme choices, app and plugin load, custom code, hosting, caching, catalog size, traffic mix, device mix, and geography. HTTP Archive also cautions that technology detection, crawl geography, headless implementations, and the CrUX-based source list affect interpretation. 1 2
The results are still useful for setting questions. A WooCommerce team has more infrastructure choices to audit, including server-side caching, a CDN, database maintenance, themes, and plugins. WooCommerce’s own documentation describes each of those as a performance lever. 8
Shopify documents a different operational mix: theme code, apps, third-party code, tag managers, images, videos, and page sections can affect storefront performance. Its guidance is to use field Web Performance reports and PageSpeed Insights, then remove or improve the actual cause. 7
Wix likewise points to media, animations, mobile content, and third-party code as practical sources of variation, and recommends reviewing real-user and lab views separately. 9 10
The decision is not “which platform wins?” It is “what does this storefront ship to the browser, and what do real visitors experience on the pages that matter?”
They answer different questions.
| View | What it measures | Best use | Common gap |
|---|---|---|---|
| Field data, such as CrUX in PageSpeed Insights | Aggregated real Chrome-user visits over a trailing 28-day period | Confirming whether visitors experience good LCP, INP, and CLS | A low-traffic or new product URL may have no field data. The tool can fall back to the whole origin. 4 |
| Lab data, such as Lighthouse | A controlled simulated page load | Finding blocking resources, layout shifts, oversized assets, and regressions | It does not represent every visitor, device, network, or interaction. 4 |
| First-party RUM | Your own users and events | Isolating affected templates, countries, devices, and interactions | It requires implementation and careful privacy handling. CrUX alone does not identify the problematic interaction. 6 |
INP makes the distinction especially important. It reflects click, tap, and keyboard interactions across a visit, and it can be missing when a user does not make a qualifying interaction. A lab tool can simulate interactions, but that result depends on which interaction is performed. Total Blocking Time is useful for diagnosis, not a replacement for field INP. 6
INP is the successor to First Input Delay, or FID. Use INP in new reporting and comparisons. 6
Start by identifying the LCP element. LCP is the render time of the largest visible image, text block, or video, so a product image may be the culprit, but it is not guaranteed to be. 5
For LCP, prioritize the visible product media and the rendering path ahead of it. Resize the primary image for its displayed dimensions, serve an efficient format where your stack supports it, avoid lazy-loading the actual LCP image, and keep below-the-fold gallery media from competing at initial load. Shopify’s guidance specifically identifies oversized visible images and delayed main images as common LCP issues. 7
For CLS, give product media and dynamic regions stable dimensions before they load. Reserve space for review widgets, promotional banners, recommendation modules, and other app content that can push the buy box or gallery down the page. 7
For INP, inventory theme JavaScript, apps or plugins, analytics tags, chat tools, and third-party embeds. Remove or defer low-value work only after checking the product flow still works. A page can look loaded while the main thread is too busy to respond promptly to a size selection or add-to-cart tap. 6 7
Image transfer bytes and total page weight should be recorded, but neither is a substitute for the Core Web Vitals. A smaller image can help, yet LCP can remain slow when server response, render-blocking work, or the wrong loading priority is the real bottleneck.
Use this workflow to build a product-page dataset for your own store. It is a recommended method, not a claim that the benchmark table above measured these URLs.
| Step | Do this consistently | Record |
|---|---|---|
| 1. Select pages | Choose your highest-traffic or highest-value product templates, plus at least one representative product per template. Keep the URL list fixed for a comparison period. | URL, template, platform, category, test date, and reason for inclusion |
| 2. Capture field data | In PageSpeed Insights, review mobile and desktop. Note whether field data is at URL or origin level, and save the 75th-percentile LCP, INP, CLS, distribution, collection period, and missing metrics. | Data level, field availability, CWV values, and pass status 4 |
| 3. Run controlled lab checks | Use the same tool and settings for every URL. For a team-owned run, pin the browser and Lighthouse versions, device preset, network profile, CPU slowdown, location, cache state, and number of runs. Use the median of repeated cold-cache runs. | Tool and version, settings, run count, median metrics, and report links or files |
| 4. Measure bytes | In the browser Network panel with cache disabled, sum transferred bytes for all requests and separately for image requests. Keep the same throttling and reload method. | Total transferred bytes, image transferred bytes, request count, and largest image requests |
| 5. Identify causes | Inspect the LCP element, render-blocking resources, image dimensions, layout-shift events, and long tasks. For INP, pair field data with a real product interaction such as choosing a variant or adding to cart. | LCP element, candidate cause, affected script or asset, and interaction tested 5 6 |
| 6. Change one thing and retest | Deploy a reversible change, repeat the same checks, and wait for the field window to mature before declaring an outcome. Log promotions, traffic shifts, and other releases. | Change ID, before/after lab values, field period, and functional QA result |
This workflow produces a more useful comparison than one isolated score. If you later group results by platform, category, traffic band, or template, show the sample size for every group and label results as observational.
For agencies, keep a simple audit sheet rather than a headline-only score. The minimum columns are: page URL, template, platform, device, field-data level, p75 LCP, p75 INP, p75 CLS, CWV pass, Lighthouse version, lab-run median, total transfer bytes, image transfer bytes, request count, LCP element, and release notes.
Make the visible product media intentional. Identify the actual LCP candidate, then prioritize that asset. Do not blindly lazy-load every image.
Remove low-value third-party work. Check apps, plugins, tags, chat, social embeds, and experiments. Keep functions that help shoppers, but test their cost on the product template. 7 8 9
Stabilize the buy box. Reserve space for images and injected components so price, variants, and add-to-cart controls do not jump after a shopper starts reading.
Test the mobile product flow. Add a variant selection, gallery swipe, add-to-cart action, and cart opening to your regression checks. This is where a healthy-looking load can still hide poor responsiveness.
Compare like with like. A lightweight single-product page, a gallery-heavy jewelry page, and a configurable product are not interchangeable. Track their templates separately before setting a target.
When the storefront work is done, keep merchandising tradeoffs explicit. Image-heavy categories such as jewelry may need detail views that matter to the purchase decision. The task is not to strip out useful media. It is to deliver the visible media efficiently and delay what the shopper does not need yet.
If you are considering a future private-label jewelry line after building a lean storefront, see how Branvas works.
For Core Web Vitals, aim for the 75th percentile of LCP at 2.5 seconds or less, INP at 200 ms or less, and CLS at 0.1 or less. Those are field targets, not a promise of conversion or search visibility. 3
No. A 90-plus Lighthouse Performance score is a good simulated lab result. A CWV pass depends on field data at the 75th percentile, so a page can have a strong lab score and still show weaker real-user results. 4
PageSpeed Insights needs enough qualifying CrUX data for the specific URL. When the URL lacks sufficient data, it can show the origin aggregate instead. Label that distinction in your report because the origin may hide product-page problems. 4
Yes. INP is the successor to FID and assesses responsiveness throughout the visit rather than only the first interaction. 6
Run a lab regression check before and after meaningful theme, app, tag, media, or template changes. Review field data on its 28-day reporting window, and keep dates and release notes beside the values so you can interpret changes honestly. 4
Part 2: Editorial Notes and Verification
The chosen primary cluster is ecommerce site speed benchmarks and related diagnostic intent. The reader’s job is to understand what good mobile ecommerce performance looks like, interpret platform-level evidence without false certainty, and run a credible product-page audit.
Shopify site speed and WooCommerce site speed are related platform-evaluation queries. They are covered as supporting terms, not independent pages.
Website speed statistics has a broader, general-web informational intent. It should be targeted in a separate statistics-led article rather than treated as this article’s core query.
The requested title was revised from “Ecommerce Site Speed Benchmarks: Product Pages Across Shopify, WooCommerce, and Wix” to “Ecommerce Site Speed Benchmarks: Shopify, WooCommerce, and Wix Storefront Data.”
This is an accuracy change. The selected published benchmark crawls a home page and one largest internal link, but does not identify product pages. It also does not publish platform rows for page weight, image payload, category, traffic band, or metric percentiles. 1 2
The article therefore uses the existing-published-dataset path. It does not claim that Branvas ran a proprietary study, does not invent test results or samples, and does not claim a downloadable aggregate CSV exists.
A live Google search for ecommerce site speed benchmarks was blocked by a CAPTCHA on October 21, 2026. No Google SERP features are claimed as observed.
Six accessible representative results were inspected: Shopify’s Website Speed Optimization for Shopify Stores, Cart2Cart’s Shopify versus WooCommerce Speed and Performance, HTTP Archive’s Ecommerce chapter, Raygun’s Core Web Vitals ecommerce analysis, Google’s PageSpeed Insights documentation, and WooCommerce’s performance documentation.
The dominant formats were optimization checklists, platform comparisons, small-sample or industry analyses, and measurement documentation. The useful gap is a transparent, mobile-first platform table paired with a lab-versus-field explanation, a documented product-page audit workflow, and explicit limits on causal claims.
The accessible Branvas blog index did not expose a complete readable article inventory in its extracted text, so the coverage check is incomplete. Search located and the review read the existing free-versus-paid Shopify theme conversion study and the PDP elements conversion study. 11 12 13
Those pieces focus on theme price, conversion, or product-page element conversion. They do not substantially serve the same performance-benchmark and measurement intent, so this is drafted as a distinct new article rather than a URL replacement.
The article contains one modest commercial internal link, to the verified How It Works page, only after the practical guidance. No Branvas catalog, pricing, shipping, integration, or feature claim is made in the publishable article.
Material performance claims are cited to sources consulted directly. The central table identifies its source, mobile basis, field versus lab distinction, and sample sizes.
The article states that platform comparisons are observational. Theme, apps or plugins, hosting, custom code, store characteristics, traffic, devices, geography, detection, and source-list bias can all confound the apparent platform differences. 1 2
The source has no field INP result for an individual low-traffic page when it lacks eligible field data, and PageSpeed Insights may show origin-level data instead. The article reports that gap rather than treating origin data as a product-page measurement. 4 6
The prior Wix URL supplied in the initial research plan returned a live 404. A current Wix Help Center performance page and its PageSpeed Insights guide were found and used instead. 9 10
No structured data was generated.
