Yes, Core Web Vitals are a ranking factor, but a small one. Google’s documentation says its ranking systems use Core Web Vitals as part of page experience, and it recommends that site owners reach good scores. The same documentation is clear that relevance wins: a page with better content for the query can outrank a faster page. So treat Core Web Vitals as a tiebreaker in search and a real factor in how visitors behave once they land. Google assesses them with field data from real Chrome users, not with the Lighthouse score.
I say “small” on purpose, because I meet two kinds of site owners. One group believes a green PageSpeed score will push them to the top. The other heard “it barely matters” and ignores a mobile LCP of six seconds. Both are wrong, in opposite directions. Here is what Google has actually said and how I weigh it in a technical SEO audit.
What does Google say about Core Web Vitals and rankings?
Google introduced Core Web Vitals in 2020 and started using them in Search as part of the page experience update, which rolled out in 2021. Its current guidance on page experience says a few things that matter here:
- Core Web Vitals are used by Google’s ranking systems.
- Good Core Web Vitals are recommended, for search and for users in general.
- Page experience is one of many signals, and Google still aims to show the most relevant content even when its page experience is not the best.
- There is no single page experience score that decides rankings.
That is the honest summary. Google has never published a weight for Core Web Vitals, and anyone who gives you a percentage is guessing.
Are Core Web Vitals a strong ranking factor?
Nobody outside Google can give a number, so I reason from what the documentation says. If relevance dominates and page experience is one signal among many, the effect is largest where the competing pages are close in relevance and quality. For a query where five pages answer the question equally well, speed and stability can decide the order. For a query where one page is clearly the best answer, a better LCP on a weaker page will not overcome it.
This is why I never sell Core Web Vitals work as an SEO trick. When a client’s rankings drop, slow pages are rarely the whole story. Content, internal links, indexing and server errors usually explain more. Core Web Vitals go on the list, with an honest label.
Which data does Google use?
Field data from the Chrome User Experience Report: real visits from Chrome users, at the 75th percentile, over a rolling 28-day window. The thresholds are the same as anywhere else.
| Metric | Good | Poor |
|---|---|---|
| LCP | 2.5 s or less | Above 4 s |
| INP | 200 ms or less | Above 500 ms |
| CLS | 0.1 or less | Above 0.25 |
INP replaced First Input Delay in March 2024. If you need a refresher on what each one measures, start with what Core Web Vitals are.
What Google does not use for this is your Lighthouse performance score. Lighthouse is a lab test of one simulated visit. It is very useful for debugging, but it is not the data behind page experience. A 100 in Lighthouse does not mean you pass, and a 60 does not mean you fail.
Do Core Web Vitals matter more than content?
No, and Google says so in its own documentation. Content that answers the query, from a source the user can trust, comes first. That said, I would not use this as an excuse. Slow pages have costs that do not depend on rankings at all: visitors who leave before the page renders, taps that seem to do nothing on a busy main thread, a buy button that moves just as someone tries to press it. Those losses show up in analytics and revenue whether or not Google adjusts your position.
What about pages that do not have enough data?
CrUX only reports URLs with enough traffic. When a URL has no data of its own, Google can group it with similar pages or fall back to origin-level data, and Search Console shows URLs grouped by similar issues. For a small site this means one fast home page does not carry the slow templates. The verdict tends to reflect the site as a whole.
Where Core Web Vitals fit in a technical SEO audit
In my audits, Core Web Vitals sit in the same section as server response, crawl health and rendering, because they share root causes. A slow first byte hurts LCP and also slows down how fast Googlebot can fetch pages. A theme that loads megabytes of JavaScript hurts INP and makes rendering harder. I explain the server side of that in technical SEO starts in the server response.
The order I follow:
- Indexing and crawl problems first. A page that is not indexed has no ranking to improve.
- Server response and caching, because they affect users, crawlers and LCP at once.
- Core Web Vitals per template, using Search Console groups, mobile first.
- Content and internal linking, which usually have the larger effect on rankings and are worked on in parallel.
When the assessment is red, the practical steps are in what to do when the Core Web Vitals assessment fails. For the WordPress specifics, the pillar is Core Web Vitals for WordPress.
Common myths I still hear
- “Passing Core Web Vitals will move me to page one.” Passing makes your pages eligible to benefit from good page experience. It does not replace relevance.
- “Google ranks by PageSpeed score.” It uses field data, and the score is a lab number.
- “Only the home page counts.” The assessment depends on the URLs and templates that get traffic, often product and article pages.
- “If rankings did not change after the fix, it did not work.” Rankings depend on many signals. Judge Core Web Vitals work by field data and by user behavior, then watch rankings over a longer period.
Frequently asked questions
Are Core Web Vitals a ranking factor on desktop too?
Google’s page experience guidance applies to Search in general, and CrUX reports mobile and desktop separately. In practice mobile deserves the attention first, since it is usually the worse of the two.
Did INP replacing FID change rankings?
INP became the responsiveness Core Web Vital in March 2024, so the data Google reads for responsiveness changed. Many sites that passed FID easily now show INP problems. Google did not publish anything about a ranking change specific to the switch, so I would not attribute ranking movement to it without evidence.
Is it worth fixing Core Web Vitals only for SEO?
I would fix them for users first, and count the SEO benefit as a bonus. If your pages are already good on field data, extra speed work will not buy you much in rankings. If they are poor on mobile, the user-side cost is usually the bigger reason to act.
If you want a clear answer on whether Core Web Vitals are holding your site back, or whether the problem is elsewhere, I review both sides as a Core Web Vitals expert.