Skip to main content
Core Web Vitals Benchmarks for Magento Stores (2026 Data)
September 19, 2026 // 2369 words // Posted in Industry & Benchmarks

Core Web Vitals Benchmarks for Magento Stores (2026 Data)

Public Magento Core Web Vitals tables often put Adobe Commerce in the middle of the ecommerce pack: roughly four to five in ten Magento origins pass all three vitals on mobile CrUX, depending on who measured and how they labelled the platform. Open a multi-page Lighthouse sample on real Magento storefronts and the picture changes around Largest Contentful Paint. Mobile Performance averages sit near the high 50s, lab LCP medians stretch well past Google's 2.5 s “good” line, and unused JavaScript shows up on almost every domain. Both views can be true. Population CrUX describes popular origins under field conditions. Portfolio monitoring needs URL-level and multi-page evidence, because catalog templates, checkout, and extension scripts decide what shoppers feel.

What follows separates those clocks, publishes a reproducible sample from Magento users we analyse in Apogee Watcher after a strong-signal platform check, and points at the remediation work that actually moves scores. The method matches our Shopify Core Web Vitals benchmarks for 2026. For ecommerce metric priorities beyond the three vitals, pair this with Performance Monitoring for E-Commerce: What Metrics Matter Most.

What counts as a reliable Magento Core Web Vitals benchmark in 2026

For Core Web Vitals, the strongest public field source remains the Chrome UX Report (CrUX). Google's methodology is clear about inclusion: pages and origins must be publicly discoverable and popular enough, data comes from eligible Chrome users, and thresholds are read at the 75th percentile over a rolling window. That is why Search Console and the field section of PageSpeed Insights matter for ranking and real-user claims, while a single Lighthouse run remains a diagnostic tool.

Google's published thresholds are unchanged for the three metrics:

Metric

Good (p75)

Needs improvement

Poor

LCP

≤ 2.5 s

2.5 s – 4.0 s

> 4.0 s

INP

≤ 200 ms

200 ms – 500 ms

> 500 ms

CLS

≤ 0.1

0.1 – 0.25

> 0.25

An origin or URL group passes Core Web Vitals when all three sit in the good bucket at p75. A Lighthouse Performance score is a different artefact: it blends lab timings under a throttled environment and is useful for regression detection, not as a substitute for CrUX pass/fail. If you need a refresher on the three metrics themselves, start with What Are Core Web Vitals? A Practical Guide for 2026.

A useful Magento benchmark therefore states four things up front: which clock (CrUX field versus Lighthouse lab), which URLs (homepage only versus category, PDP, cart, checkout), how scores are aggregated (single URL versus median or mean across pages), and the collection window. Platform marketing and vendor health reports often quote pass rates without that scaffolding. Agencies managing twenty Magento clients need the scaffolding more than another green screenshot.

Sources:

Multi-page lab sample from Watcher's verified Magento users

We keep Magento and Adobe Commerce storefronts in Watcher and run multi-page PageSpeed Insights analyses that store Lighthouse lab metrics and CrUX field payloads when Google returns them. For this snapshot we took the latest domain report per Magento-verified user after a strong-signal platform check (n = 76 stores with aggregated reports; 80 users carried the verified Magento tag; reports generated between late August and mid-September 2026). Verification requires Magento-specific evidence such as x-magento-* headers, Magento_ modules, text/x-magento-init, Magento cookies, or /static/version together with form_key. Loose strings that falsely labelled Next.js and Salesforce Commerce Cloud sites as Magento were excluded.

Each report averages Lighthouse metrics across the URLs selected for that domain (median 13 analysed pages per store; 1,195 page runs in total). Values below are store-level averages of lab runs, not single-URL CrUX p75s, so a store that looks healthy on one PDP can still drag the average when cart and category templates are included.

Mobile and desktop Lighthouse Performance

Grouped bar chart of Magento verified users Lighthouse Performance store averages for mobile and desktop across min, P25, median, P75, max, and mean (n=76), with a Perf ≥ 90 reference line

Slice

Mobile Performance (avg)

Desktop Performance (avg)

Minimum

27

39

25th percentile

43

62

Median

58

75

75th percentile

70

87

Maximum

93

98

Mean

58

74

Half of the sample sits at or below a mobile Performance average of about 58. Forty-eight of 76 stores clear a mobile average of 50, 19 of 76 clear 70, and only 1 of 76 store averages reached 90 on mobile. Desktop is kinder in the same runs (median about 75), which matches what agencies see when a client forwards a desktop-only screenshot and assumes the site is fine. Compared with our Shopify Watcher sample (median mobile Performance about 51 on 64 stores), this Magento set lands a little higher on the Performance dial while still failing Google's lab-friendly Performance ≥ 90 bar almost everywhere. The shared pattern matters more than the six-point gap: multi-page Magento lab averages remain a remediation queue, not proof that the storefront is done.

Mobile lab Core Web Vitals timings (store averages)

Metric

Median

75th percentile

Notes in this sample

LCP (s)

8.2

12.6

2 / 76 store averages ≤ 2.5 s

INP (s)

0.22

0.30

34 / 76 store averages ≤ 0.20 s

CLS

0.027

0.064

63 / 76 store averages ≤ 0.1

CLS is often already in a good lab band even when LCP is not. LCP is the structural problem. Multi-page mobile averages in the 6–13 s range do not mean every URL fails CrUX at that severity, but they do mean Lighthouse is consistently flagging heavy LCP candidates across templates. That is the signal agencies should take into a remediation backlog before arguing about a two-point Performance score change.

CrUX origin categories when field data exists

Not every user has origin-level CrUX on the report. Where mobile origin overall category was present (n = 46), we saw 15 FAST, 18 AVERAGE, and 13 SLOW. Origin LCP was FAST on 35 of those stores, INP FAST on 41, and CLS FAST on 39. Field data is often healthier than multi-page lab averages on the same domains, especially for LCP and INP, because lab throttling and averaging across many templates punish media-heavy PDPs that may still pass origin-level CrUX when popular URLs are lighter.

Recurring Lighthouse opportunities

Horizontal bar chart of recurring mobile Lighthouse opportunities across 76 Magento stores, led by unused JavaScript 72/76 and unused CSS 66/76

Across the 76 latest reports, the most common mobile opportunities were:

Opportunity

Stores where it appeared

Reduce unused JavaScript

72 / 76

Reduce unused CSS

66 / 76

Avoid multiple page redirects

38 / 76

Minify JavaScript

26 / 76

Initial server response time

13 / 76

Minify CSS

8 / 76

Unused JavaScript is effectively the default Magento finding in this sample. Theme and UI component code, extension scripts, analytics, and personalisation layers compete for the same main thread that INP and Total Blocking Time care about. Redirect chains still show up on enough domains to deserve a separate checklist item when agencies inherit migrated catalogs or multi-store URL maps.

Attention-free score across the Magento sample

Two charts of Magento Attention-Free Score for 76 verified users: distribution percentiles with median 4%, and store counts by band including 34 at 0% and 0 at 100%

Performance averages answer “how green is the typical page?”. The Attention-Free Score on Watcher domain reports answers a stricter triage question: what share of completed page×device tests pass all lab gates at once (Performance ≥ 90, Accessibility / Best Practices / SEO ≥ 80, LCP ≤ 2.5 s, CLS ≤ 0.1, INP ≤ 0.2 s with Total Blocking Time as a fallback when INP is missing). One hundred percent means no page needs attention on either strategy.

We computed that score for the same 76 latest Magento reports:

Slice

Attention-free %

Minimum

0

25th percentile

0

Median

4

75th percentile

17

Maximum

71

Mean

11

None of the 76 stores reached 100%. Only two cleared 50% (paradoxlabs.com at 71% and evrig.com at 61%). Thirty-four sat at 0%, and 49 were under 10%. Across every completed test in the cohort (2,325 page×device runs), only 12% were fully clear. Summary status landed on “Attention recommended” for 74 stores and “Watch” for the other two; none were a clean “Pass”.

The most common top gap on the failing scoreboard was Performance (66 stores). That aligns with the multi-page averages above: a median mobile Performance of 58 can coexist with almost every store failing the Perf ≥ 90 gate on most templates, especially once LCP ≤ 2.5 s is required in the same pass/fail set. Agencies get clearer decisions when they read Attention-Free as the portfolio triage dial and CrUX as the ranking dial, rather than treating the two as substitutes.

Why Magento Core Web Vitals still vary store to store

Two shops on Magento 2 / Adobe Commerce can land in different buckets for reasons that never appear in a platform marketing page:

  • Extension footprint. Reviews, loyalty, chat, configurators, and A/B tools add script weight on category and PDP templates.

  • Frontend stack. Luma-era RequireJS bundles, Hyvä, custom headless storefronts, and heavy page builders change what Lighthouse sees even when the catalog is identical.

  • Media strategy. Hero video, large product galleries, and unprioritised LCP images dominate mobile LCP in lab runs.

  • Template mix. A clean homepage can hide a slow cart drawer or a script-heavy layered navigation when you only test one URL.

  • Caching and TTFB. Full-page cache hits versus misses, Varnish/CDN configuration, and cold admin-side caches change first-byte timings that then delay LCP.

  • Traffic shape and geography. CrUX inclusion and p75 values move with real visitor mix; lab runs do not.

Platform-level medians help set expectations in a roadmap review, but they do not replace scheduled checks on the URLs that drive revenue. Population CrUX tables stay useful as context; multi-page samples are the day-to-day view we use when an agency asks which Magento client to fix first.

Lab Lighthouse scores versus CrUX field data on Magento

Reporting stays clearer when lab and field stay in separate columns:

Question

Prefer

Does Google’s page experience view look healthy?

CrUX / Search Console / PSI field (p75)

Did last week’s release or extension change regress templates?

Scheduled Lighthouse (lab), same URL set

Are we comparing to a platform CrUX table?

Population studies with stated n and month

Are we comparing agency client A to client B?

Same tool, same URL roles, same aggregation

Watcher domain reports already separate lab score cards from field methodology notes (median of URL-level p75s where present, origin badge when available). That separation belongs in client decks too. A green origin badge with a mobile Performance average of 45 is not a contradiction; it is a prompt to inspect which templates the lab average is punishing. For portfolio monitoring design, see Core Web Vitals Monitoring Checklist for Agencies and How to Set Up Automated PageSpeed Monitoring.

What to fix first when Magento Lighthouse opportunities repeat

When unused JavaScript and unused CSS dominate the opportunity list, a useful starting set is the money path (home, top category, top PDP, cart, checkout) rather than a homepage-only screenshot contest:

  1. Measure the same URLs on a schedule. Lab averages move when discovery adds templates, so locking the set before debating a three-point Performance change keeps the comparison honest.

  2. Attack LCP candidates on the worst templates first. Hero and primary product imagery, font loading, and above-the-fold critical CSS usually repay the work; lazy-loading the LCP image is a common Magento misstep.

  3. Shrink the extension and theme JavaScript budget. Removing unused modules, deferring non-critical RequireJS components, and challenging each chat or review widget on PDP reduces the unused-JS finding that dominates this sample.

  4. Check redirects and HTML caching. Multi-hop store codes, trailing-slash policies, and cold full-page cache misses show up as redirects or slow document response before paint work begins.

  5. Reconcile with CrUX monthly. If origin field data is FAST while lab LCP is ugly, document which templates are lab-only pain and which URLs Search Console actually groups.

Trimmed Magento storefronts in our sample can still clear mobile lab averages in the mid-80s to low-90s (for example jajuma.de, loviux.com, and paradoxlabs.com in this pull). Heavier catalogs and extension stacks land in the high 20s to mid-30s with lab LCP well into double-digit seconds. The platform label is the same; the implementation load is not.

How to run a repeatable Magento CWV cohort each month

A monthly Magento cohort holds up better when the origin list and URL roles stay fixed:

  1. Keep a fixed list of Magento / Adobe Commerce origins (clients plus any public cohort you track).

  2. Run the same multi-page URL roles every month (home, category, PDP, cart, checkout when reachable).

  3. Publish store-level lab averages and, separately, origin CrUX categories when present.

  4. Track unused JavaScript and unused CSS occurrence counts so extension creep is visible.

  5. Annotate releases: Magento upgrades, Hyvä or theme changes, extension adds, CDN or FPC changes, and major catalog campaigns.

That schedule turns a one-off benchmark into a monitoring habit. If you want the same workflow without rebuilding spreadsheets, start a free Watcher check or create an account and schedule the money-path URLs you already care about. The charts and tables above are a September 2026 snapshot; the monthly loop is what keeps Magento CWV from becoming another stale slide.

FAQ

What is a good Magento Core Web Vitals score in 2026?
For ranking and real-user claims, use CrUX or Search Console at p75: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. Lighthouse Performance averages in the 50s are common on multi-page Magento lab samples and are not a CrUX pass/fail substitute.

Why is Magento LCP so high in lab tests?
Throttled Lighthouse plus heavy heroes, product media, and JavaScript-heavy templates inflate store averages when many URLs are included. Origin CrUX can still look healthier if popular URLs are lighter than the full template set.

Do Magento stores usually pass Core Web Vitals in the field?
Population studies in mid-2026 place Magento all-CWV mobile pass rates roughly in the 40–52% range depending on the dataset. That is orientation only; your client's origin is the scoreboard that matters.

Is unused JavaScript inevitable on Magento?
It is extremely common in our sample (72 / 76 stores), but it is not inevitable. Extension audits, lighter frontends, and deferred non-critical scripts reduce the finding. Count scripts on money-path templates before accepting “Magento is just heavy” as the final answer.

How does this compare with Shopify?
Our Shopify Watcher sample (n = 64) showed a median mobile Performance of about 51 with unused JavaScript on 61 of 64 stores. This Magento sample (n = 76) shows a median about 58, with unused JavaScript on 72 of 76. LCP remains the hard lab problem on both platforms. Compare like with like: same clocks, same multi-page aggregation.

Should we migrate off Magento for Core Web Vitals?
Not based on a lab average alone. Fix LCP candidates, extension weight, and caching first; re-measure the same URL set; then decide whether a frontend rebuild or platform change is the cheaper path for that catalog.

What does an Attention-Free Score near 0% mean for Magento?
It means almost every completed mobile and desktop test failed at least one lab gate, usually Performance ≥ 90 and/or LCP ≤ 2.5 s. It does not mean origin CrUX is automatically Poor. Attention-Free helps prioritise templates; Search Console or PSI field data supports ranking claims.

References

← Back to Blog
⁂⁂⁂⁂

Related Posts