Core Web Vitals failing in real-user data but passing in Lab — Magento

[vishves shah]

We’re working on a Magento website and are facing an issue with Core Web Vitals.

Our PDP (Product Detail Pages) and PLP (Product Listing Pages) are sometimes failing LCP or INP in real-user/field data. However, when we test the same pages using PageSpeed Insights/Lighthouse lab testing, the results show as Good/Passed.

We have already made several performance optimizations, but we’re still seeing the difference between the lab results and real-user data.

Has anyone faced something similar with Magento?

What would be the best way to identify what is actually causing the LCP/INP issues for real users when the lab results are passing?

Any guidance or suggestions would be greatly appreciated

We deployed our fixes on 20 Sep 2026. Our own RUM (built on web-vitals.js) shows this for mobile, indexable pages only:

Before the fix (16 Sep, p75):

- CLS: 0.233

- LCP: 2264ms

After the fix (20–24 Sep, p75):

- CLS: 0.004–0.018 per day (Chrome only: 0)

- LCP: ~1.0–1.3s per day (Chrome only: 1280ms)

- INP: 80–96ms (Chrome only: 96ms)

- TTFB: ~600–800ms (Chrome only: 587ms)

The numbers have been stable every day since the deploy.

Our questions:

1. Are we good now? Do these numbers look safe for passing mobile Core Web Vitals, or are any of them too close to the threshold?

2. Is there anything we should still improve? For example, is TTFB around 600–800ms worth reducing further to protect LCP?

3. When will GSC show passing? Since CrUX uses a 28-day rolling window, we expect it to reflect the 20 Sep fixes around 18–20 Oct. Is that right, and how much extra lag should we expect in the Search Console report?

4. Should we click "Validate Fix" in GSC now, or wait until PageSpeed Insights field data shows passing?

Any update or pointers would be a big help. Happy to share more data if needed.

[Barry Pollard]

Those look like pretty good numbers.

TTFB is a little higher than ideal, but often that is traffic from ads and redirect sources that may not be under your control. It would be worth understanding if that;s the case here or if you have an actual server-side issue that could be improved.

While it will take 28 days to see the full impact in CrUX, you can usually get some idea by looking at the number of good sites in the expanded view in PageSpeed Insights:

As long as the number of "Good" page loads are increasing each day, then it sounds like you've solved the issue. After the number of "good" page loads pass 75% your overall number should reflect.

More details in this article: https://www.smashingmagazine.com/2021/04/complete-guide-measure-core-web-vitals/#the-chrome-user-experience-report-crux

And no you shouldn't have to do anything in Google Search Console as it should show the latest CrUX details.

Thanks,

Barry

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/179515fa-62b8-44d7-a23c-463b19bcca88n%40googlegroups.com.

[vishves shah]

Thanks for the update, It seems that page is improving but our LCP is not improving and in webvital logs it says that it says it will be pass can you help me with this?

Thank you again.

[Barry Pollard]

It's not been 28 days since you deployed the fix. So it's not surprising the headlining LCP number may not have moved yet. Did you read the article I linked? Are the % of sites improving each day? Can you share the URL you are talking about?

To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/d11ebbaf-e5a6-4796-9f37-1fefca3d758en%40googlegroups.com.

[vishves shah]

Sure here is the URLS -  It is flagging to every url of our site in mobile.

https://www.buyritebeauty.com/contemporary-black-leather-chair-with-metal-encasing-frame/ 

https://www.buyritebeauty.com/manicure-pedicure/

--

Vishves Shah Founder | Solution Architect | Solution Consultant, AADIMUM +91-997-891-3133  |  vis...@gmail.com

[Barry Pollard]

We don't have URL-level data in CrUX for those URLs and CrUX is showing those as passing on mobile, though failing on desktop.

The screenshot you are showing is from Google Search Console, which does use the same underlying data as CrUX, but segments those on page types. That is supported by the Search Team, rather than the Chrome team (which I'm on and which this group is for), so I can't tell you exactly why this is happening on their tool but it would appear they've segmented the CrUX data into different groups and some are slow, and some are fast, even if the aggregate number we see in CrUX is faster overall (for mobile).

However when I try to load https://www.buyritebeauty.com/contemporary-black-leather-chair-with-metal-encasing-frame/  it loads reasonably fast (800ms).

Then, when I try https://www.buyritebeauty.com/contemporary-black-leather-chair-with-metal-encasing-frame/?test=1234 it loads slow (>2.7 seconds).

Reloading https://www.buyritebeauty.com/contemporary-black-leather-chair-with-metal-encasing-frame/?test=1234 loads fast  (800ms).

But loading https://www.buyritebeauty.com/contemporary-black-leather-chair-with-metal-encasing-frame/?test=5678 it loads slow again  (>2.7 seconds).

This shows your server is very slow to respond, but if the page has been requested recently it's faster (because it's cached in your server infrastructure).

CrUX will be made up of real users, some of whom will be lucky to get those cached opages, many of whom will not. And if you're repeatedly testing the same page, then it will more likely get the fast pages and so mask the problem. That's why I like to use those cache-busting URL params (?test=XXXX) to see if that show s the full impact.

I don't know what you fixed on 20th September, and why that seems to solve the issue in RUM, but to me there is a still a real problem here. And it's unsurprising GSC (and CrUX on desktop) is showing high LCP numbers. However, maybe you made enough fixes, and maybe you get enough cached page views that uncached page views are a minority, and this will resolve when the full 28-day cycle feeds though. But I think there's still a real issue here you should dig into to see why your server response times are so slow.

Hope that helps,

Barry

[vishves shah]

Thanks — that's a really useful technique, and I've added it to our toolkit.

I reproduced your result exactly. Measuring server time as TTFB minus TLS-complete, so network latency is excluded:

• ?t=<new> → cold → 2.94s → MISS

• ?t=<same> → warm → 0.51s → HIT

• ?t=<new> → cold → 2.84s → MISS

• ?t=<same> → warm → 0.53s → HIT

• ?t=<new> → cold → 2.94s → MISS

• ?t=<same> → warm → 0.43s → HIT

So an uncached Magento render really is around 2.9s, very consistently. No argument there.

Where it gets interesting is what happens with parameters that real visitors actually arrive with. Our full-page cache strips marketing parameters from the cache key, so these all remain cache hits even with never-before-seen values:

• Clean URL → 0.575s HIT

• ?gclid=<unique> → 0.554s HIT

• ?utm_source=google&utm_medium=cpc&... → 0.651s HIT

• ?srsltid=<unique> → 0.465s HIT

• ?fbclid=<unique> → 0.611s HIT

Only an arbitrary parameter such as ?test=1234 produces a miss. Combined with the cache warmer running across the catalog, this means the 2.9s cold-render path is real, but it isn't something the majority of normal marketing traffic should be experiencing.

So what we can do here since our pages will always comes from cache only, It was working 2 month back but all of sudden it is failing. Can you please help me?

[Barry Pollard]

I don't really know how to help further when I'm only getting part of the picture here. I can't explain why your RUM numbers are so much better than CrUX, but maybe it is just taking the full 28-days to filter through.

CrUX is definitely showing that TTFB is a problem (particularly on desktop) and I can repeat that fairly easily. That has not improved since your fix (whatever that was) was deployed. So not sure why you're sure "it isn't something the majority of normal marketing traffic should be experiencing"?

The other issue to consider if TTFB includes redirect times, and that may be causing additional slow down even for your cached pages. But again that should be shown in RUM numbers.

[vishves shah]

Thanks for the advice. 

We’ve noticed a positive trend in our LCP performance. The number of pages failing the LCP assessment in Google Search Console has decreased from approximately 1,156 last week to 1,027 currently.

However, while investigating the remaining URLs in the failing LCP group, we noticed a discrepancy. We tested both a product detail page (PDP) and a product listing page (PLP) using PageSpeed Insights, and both are showing as passing.

Examples:

• PDP: https://pagespeed.web.dev/analysis/https-www-buyritebeauty-com-eye-vac-pro-electronic-vacuum/r2hj9ekjia?utm_source=search_console&form_factor=mobile&hl=en_GB

• PLP: https://pagespeed.web.dev/analysis/https-www-buyritebeauty-com-shampoo-area/yyzx7ykskv?utm_source=search_console&form_factor=mobile&hl=en_GB

Could you please help us understand why these URLs are still appearing in the failing LCP group in Google Search Console while PageSpeed Insights indicates that they are passing? We’d also like to clarify whether this discrepancy is related to the CrUX field data reporting period, insufficient real-user data, or a delay in Google Search Console updating its assessment.

Any guidance on how we should interpret these results and verify the actual field performance would be appreciated.

[Tony McCreath]

When I first visit the site, I see a Cloudflare security thing for a second or so. Could that cause a longer LCP for new visitors?

You could include the server caching status in the HTML and then send it to, say, GA4 so you can report on it. Or maybe you can get that data directly from the server?