Short answer
Google confirms that Core Web Vitals are used by its ranking systems, but also that good scores do not guarantee good rankings and that relevant, helpful content comes first. In practice they act mostly as a tie-breaker between pages that are otherwise similar. Poor scores rarely cause a sharp traffic drop on their own, but they cost you visitors every day, which is reason enough to fix them.
Core Web Vitals sit at an awkward point in SEO. Some treat them as a top ranking factor; others dismiss them as irrelevant. Both views miss what Google has actually said.
The honest position is in the middle, and it changes how you should prioritise speed work against everything else on your list.
The three Core Web Vitals
| Metric | What it measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds when someone taps or clicks | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps around while loading | 0.1 or less |
Each is judged at the 75th percentile of real visits, separately for mobile and desktop. A page passes when three quarters of real visitors get a good experience. INP replaced the older First Input Delay metric in March 2024.
What Google has actually confirmed
- Core Web Vitals are used by Google’s ranking systems. Google says so in its page experience documentation.
- There is no single page experience signal. Google describes page experience as a collection of things its core systems look at, not one score.
- Good scores do not guarantee top rankings. A fast page with weaker content will not outrank a more helpful one because of speed.
- Page experience is not listed as a ranking system. It no longer appears in Google’s official guide to ranking systems, though Core Web Vitals are still documented.
Read together, these say the same thing: speed and stability matter, but relevance and quality matter more.
How much do they really matter?
Google has described page experience as something that can help decide between pages of similar quality. That makes Core Web Vitals most important where competition is close, such as commercial searches with several strong, similar pages.
- They rarely explain a large ranking drop. Sites do not usually lose half their traffic because LCP slipped from 2.3 to 2.8 seconds.
- They can decide close contests. When two pages answer a search equally well, the faster, more stable one has an edge.
- They always affect visitors. Slow, jumpy pages lose people before they read anything, whatever the rankings.
A short history
- June to September 2021: the page experience update brings Core Web Vitals into ranking on mobile.
- February to March 2022: the desktop page experience update extends them to desktop.
- March 2024: INP replaces First Input Delay as the responsiveness metric.
- Since 2023: Google stops presenting page experience as a single system and describes it as part of core ranking.
Field data and lab data
Google’s ranking systems use field data: measurements from real Chrome users, collected in the Chrome User Experience Report over a rolling 28 days.
- Search Console’s Core Web Vitals report shows that field data, grouping similar pages together.
- PageSpeed Insights shows field data at the top, where it exists, and a lab test underneath.
- Lab scores, such as a Lighthouse result out of 100, are for finding problems. They are not what Google ranks on.
A perfect lab score with poor field data means real visitors are still struggling. Smaller sites may have no field data at all, in which case the lab test is a guide to what to fix, not a measure of ranking impact.
An example from this site
In October 2026 this site’s own performance was audited. Two problems stood out, and neither showed up as an obvious error.
- Page caching had been switched off. Every visit made the server build the page from scratch, taking around a second before anything could load. Turning caching on cut that to a few milliseconds for cached pages.
- Unused plugins were loading files on every page. An ecommerce plugin with no products and a block library with no blocks in use added about ninety stylesheets per page. Loading them only where needed cut stylesheets from 119 to 26 on most pages.
Neither change touched the content, and both took less than a day. Whether they move the site’s Core Web Vitals will show in the field data over the following 28 days, which is the honest way to judge any speed work.
Checking your own Core Web Vitals in ten minutes
- Open the Core Web Vitals report in Search Console and start with mobile.
- Look at the groups marked poor or needing improvement, and note which metric failed for each.
- Open one example URL from each group in PageSpeed Insights.
- Read the field data at the top first. That is what real visitors experienced over the last 28 days.
- Use the lab diagnostics underneath to see what is causing the problem.
- Note which template the page uses. The same fix usually applies to every page built on it.
If Search Console shows no data at all, your site may not have enough Chrome visitors for a field report. In that case, use the lab test as a guide and judge improvements by how the pages feel on a mid-range phone.
What to fix first
- For slow LCP: server response time, oversized images, and stylesheets or scripts that block the page from showing.
- For poor INP: heavy JavaScript, especially third-party scripts for ads, chat widgets and tracking.
- For high CLS: images and embeds without set dimensions, adverts that push content down, and late-loading fonts.
Start with whatever affects every page, such as hosting, caching and site-wide scripts. One template-level fix helps thousands of pages at once.
Third-party scripts: the hidden cost
On many sites the biggest drag on speed is not the site itself but what it loads from elsewhere. Advertising code, chat widgets, tag managers, testing tools and social embeds each add weight, and several can slow responses to every tap.
- List every third-party script on your main templates.
- Ask what each one earns or provides, and whether anyone still uses it.
- Remove what nobody needs, and load the rest only on pages that use them.
Plugins work the same way. As the example above shows, tools installed once and forgotten can load on every page for years.
Can poor Core Web Vitals cause a traffic drop?
Rarely on their own, and almost never sharply. If traffic fell on the date of a confirmed core update, look at content first. If it fell gradually after a redesign that made pages heavier, speed and stability are worth checking alongside everything else the redesign changed.
The more common link is indirect: slow pages lose visitors, and pages that frustrate people tend to lose ground over time. A wider diagnosis starts with why did my website traffic drop overnight.
What not to do
- Do not chase a perfect lab score at the expense of features people use.
- Do not strip useful content to save a few kilobytes.
- Do not judge success by one test run. Lab results vary from run to run; field data over weeks is what counts.
Google reads the mobile version of your pages for ranking, so mobile figures matter most; see mobile-first indexing explained. Where page experience fits among Google’s systems is covered in Google’s ranking systems explained.
Wondering whether speed is holding you back?
Speed work is worth doing, but rarely the first thing to fix after a drop. Send your Search Console access and within 48 hours I will tell you where it ranks on your list.
Get free recovery audit