Core Web Vitals in WordPress fail on field data, not on your PageSpeed score. The score is a single simulated lab test. The assessment uses real Chrome visitors over a trailing 28 days, measured at the 75th percentile. Google ranks on the second one, which is why a green score proves nothing.
The most common version of this I get handed is not a question about metrics. It is a screenshot of a green PageSpeed score sitting next to a Search Console email saying the site failed, and a reasonable person asking which one is lying.
Neither is. They measure different things. Once you know which one Google ranks on, most of the confusion on this topic disappears, and almost every guide buries that under a list of fixes.
Why does a 95 PageSpeed score fail the assessment?
Because Core Web Vitals in WordPress are judged on real visits, and the big coloured number is not. PageSpeed Insights shows you two things and people read them as one.
The score is lab data: a simulated page load, run once, on a modelled device and connection. The Core Web Vitals section above it is field data, taken from the Chrome User Experience Report, which means real Chrome users over a trailing 28-day window. Google assesses it at the 75th percentile{target=”_blank” rel=”noopener”}, so 75% of actual visits must hit the threshold.
Google’s own documentation{target=”_blank” rel=”noopener”} says it plainly: good lab data does not necessarily mean real users are having a good experience.
What is the URL versus Origin toggle?
It is the switch that causes more misdiagnosis than anything else on the page. If a URL has too little traffic in 28 days, PageSpeed Insights quietly falls back to Origin data, which is the average across your whole domain. Plenty of people diagnose one page while looking at sitewide numbers and never notice the switch.
Check it before you conclude anything. A page that looks fine on Origin data can be the worst page on the site.
What does “insufficient data” mean?
It means Google does not have enough real visits to judge yet. It does not mean you failed.
Smaller sites often see no field data at all. Google does not publish a minimum traffic figure, so there is no number to aim at. Until field data appears, lab tests and a real phone are what you have.
What are the Core Web Vitals thresholds?
Three measurements, three different problems.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | How fast the main content appears | ≤ 2.5s | 2.5 to 4.0s | > 4.0s |
| INP | How fast the page responds to clicks | ≤ 200ms | 200 to 500ms | > 500ms |
| CLS | How much the layout jumps around | ≤ 0.1 | 0.1 to 0.25 | > 0.25 |
Those are Google’s published thresholds{target=”_blank” rel=”noopener”}. They have not changed since Interaction to Next Paint replaced First Input Delay in March 2024. If a guide still mentions FID, it is out of date.
Why is INP not a loading problem?
Because it measures what happens after the page has loaded, not how fast it loaded.
FID only measured the delay before the browser started processing your first interaction. INP measures the full time from interaction to the screen updating, across every interaction in a visit, then reports the worst one.
That is exactly why a site feels fast to its owner and fails anyway. The owner loads the homepage and looks at it. Visitors click things.
On WordPress, high INP almost always traces to JavaScript competing for the main thread. The usual sources are page-builder scripts, stacked plugins each adding their own event listeners, and third-party tags like chat widgets and marketing pixels.
Roughly 40% of website origins on mobile failto meet the necessary 200ms threshold for Interaction to Next Paint (INP), according to data from the Chrome UX Report featured on SitePoint.
How do I find which interaction is slow?
Reading that INP is high tells you nothing about what to fix. Three tools narrow it to the specific interaction.
The Web Vitals Chrome extension reports live INP as you use your own site. Click the menu, open an accordion, submit a form, and watch which action spikes the number. This is the fastest way to reproduce the problem in ninety seconds.
Chrome DevTools, Performance panel. Record while you perform the slow interaction, then look for long tasks on the main thread. The flame chart names the script file responsible, which is usually enough to identify the plugin.
Google’s web-vitals JavaScript library logs real INP from real visitors, with attribution data naming the element and the script. This is the only one of the three that tells you what your actual users experience rather than what you experience on your own machine.
Start with the extension. Most of the time the culprit is obvious within a few clicks, and you never need the other two.
Do Core Web Vitals differ on mobile and desktop?
Yes, and they are assessed separately. This matters more than most guides admit.
The Chrome User Experience Report collects mobile and desktop data as separate sets, and Search Console reports them in separate tabs. Mobile is almost always the weaker of the two, because phones run slower processors and parse JavaScript more slowly than the laptop you are testing on.
The practical consequence: check the mobile assessment first. A WordPress site passing on desktop and failing on mobile is the normal case, not the exception, and optimising against your desktop numbers means optimising the half that already works.
Which metric should you fix first?
Fix whatever is in the red band, because that is what is actually costing you.
Guides disagree on a universal order. Some say start with LCP. Others rank by difficulty and put INP first. Neither rule beats reading your own report and starting with whatever is rated Poor on mobile.
One rule does hold: do not optimise a metric that is already green. Moving LCP from 1.8 seconds to 1.4 seconds changes nothing in Google’s assessment. That is where a lot of optimisation budget quietly disappears.
What causes Core Web Vitals to fail on WordPress?
Most WordPress failures trace to the same handful of causes, and each one hits specific metrics.
| Cause | Hurts |
|---|---|
| Page builder overhead | LCP, INP, CLS |
| Plugin sprawl and third-party scripts | INP |
| Unoptimised or unsized images | LCP, CLS |
| Heavy multipurpose theme | LCP, INP |
| Slow hosting and server response time | LCP |
| Fonts loading without fallback sizing | CLS |
| Ads and embeds with no reserved space | CLS |
Page builders deserve the top row. The Elementor code-weight figure goes here, with the consultancy named and linked. My guide to speeding up an Elementor site covers the fixes.
If the answer turns out to be structural rather than fixable, moving away from Elementor covers that decision honestly.
For the underlying techniques, start with fixing a slow WordPress website. Images get their own guide, since unsized and unoptimised images hit two metrics at once.
Stores are their own case. A WooCommerce store carries cart fragments and checkout scripts that a brochure site never has to load.
One honest limit: if the root cause is your hosting or your theme, no plugin fixes it. A caching plugin cannot make a slow server fast, and no optimisation setting undoes a theme that ships unused CSS on every page.
Why has my fix not shown up in Search Console yet?
Because field data runs on a 28-day rolling window.
Change something today and the lab score moves within hours. The assessment does not, because it waits for enough new real-user sessions to shift the 75th percentile. That gap catches people out constantly. They fix things, check a week later, see no change, and assume the work failed.
Two rules follow.
Wait a full month before judging a field result. Verify the fix in lab data and on a real phone in the meantime, but do not expect Search Console to agree yet.
Change one significant thing per cycle. Deploy five changes and the number moves a month later with nothing to tell you which one did it. That matters most when one of the five made things worse. Test each change on a staging copy before it reaches real visitors.
How much do Core Web Vitals affect rankings?
They are a confirmed ranking signal and a tie-breaker rather than an override.
Between two pages with similar relevance and authority, the faster one has an edge. Against a page with better content and stronger links, passing does not close the gap. Anyone selling Core Web Vitals as a primary ranking lever is overstating it.
The stronger argument is commercial. Slow, unstable pages lose visitors before they convert, and that costs money regardless of where you rank.
There is also a 2026 angle. Pages that render fast and cleanly are easier for crawlers and answer engines to parse, which matters more as buyers ask AI tools instead of scrolling results. My guide to AI visibility covers that shift.
Key takeaways
The PageSpeed score is lab data. The Core Web Vitals assessment is field data from real Chrome visitors over 28 days. That is why a fast-looking site fails. Check the URL versus Origin toggle before diagnosing anything, and treat “insufficient data” as missing rather than failed.
Check mobile before desktop, because they are assessed separately and mobile is almost always the weaker set.
If INP is your problem, it is a post-load JavaScript problem, not a loading one. Reproduce it with the Web Vitals extension before you change anything, so you are fixing a specific interaction rather than guessing at plugins.
Fix whatever is red, leave green metrics alone, change one thing per cycle, and give any change a full month before judging it in Search Console.
Frequently asked questions
Do Core Web Vitals work differently on mobile and desktop?
They are measured and assessed separately. The Chrome User Experience Report collects each as its own data set, and Search Console reports them in separate tabs. Mobile is usually the weaker one, because phones parse JavaScript more slowly than a development laptop. Diagnose mobile first.
Can a caching plugin fix INP?
Usually not. Caching stores a prebuilt page so the server responds faster, which helps LCP. INP is main-thread JavaScript running after the page has loaded, and a cached page runs exactly the same scripts. Reducing or deferring the JavaScript is what moves INP, not caching it.
How much traffic does my site need before Google shows field data?
Google does not publish a minimum. The Chrome User Experience Report needs enough visits from Chrome users who have opted into reporting before it will publish a result for a URL. Low-traffic pages commonly show nothing at page level while the whole domain still reports Origin data.
Where do I find Core Web Vitals in Search Console?
Under the Experience section, in the Core Web Vitals report, split into separate mobile and desktop views. Search Console groups similar URLs together, so one fix can move a whole group at once. The Validate Fix button starts a re-check that runs on the same 28-day cycle.
Do Core Web Vitals apply to pages behind a login?
In practice, no. Field data only accumulates where enough opted-in Chrome users visit, and logged-in areas rarely reach that volume, so they usually show no assessment. Those pages are not in search results either. Optimise them for your users, not for the report.
Will switching WordPress themes fix my Core Web Vitals?
Sometimes, and it is the last resort rather than the first. A heavy multipurpose theme loading unused CSS on every page does cap what any plugin can achieve. But a theme change rebuilds your site, so confirm the theme is genuinely the bottleneck before committing to it.
Not sure which metric is actually costing you?
Core Web Vitals work is easy to spend money on and hard to spend it well. That is truest when the real cause is the host or the theme rather than anything a plugin can reach, because that is the case where a month of optimisation work changes nothing.
Survyc is an AI-first digital agency, and our WordPress speed optimization service starts by telling you which metric is worth fixing and which is already fine. Send us the URL or email info@survyc.com. If you want Core Web Vitals in WordPress watched month to month rather than checked once, our WordPress care plans cover that.
