Do Core Web Vitals affect rankings?

Yes, as a small signal within page experience, and mostly as a tie-breaker between otherwise similar pages. The larger effects are indirect: slow pages lose visitors before they convert, and a performance regression that hits a whole template can coincide with a ranking drop across that template.

Why does my page pass in Lighthouse but fail in Search Console?

Lighthouse is one simulated load. Search Console is the 75th percentile of real visits over 28 days, many of them on slower devices and connections than the simulation. The field data is the one that counts. Use the lab tool to find causes, not to declare victory.

How long after a fix does the report change?

Field data is a rolling 28-day window, so a fix shows fully after about four weeks, and partially from the first week. If nothing has moved after six weeks, the fix did not reach the visits that were slow, which usually means the wrong template or the wrong device class.

Should I fix desktop or mobile first?

Mobile, almost always. It fails more often, it is where most visits are on most sites, and the fixes carry over to desktop. The exception is a B2B site whose field data shows most visits and most failures on desktop.

Core Web Vitals: What to Fix First

Core Web Vitals reports produce a particular kind of panic. A dashboard goes orange, someone runs a lab tool, and a week disappears into shaving kilobytes off a script that was never the problem. The site is no faster for real visitors and the report is still orange.

The way out is to read the right number first, fix the one template that is dragging the group down, and work the metrics in the order they usually fail. This guide is the order we use. It assumes nothing about your stack and it does not require a 100 in Lighthouse, which is not a goal anyone should have.

Key takeaways

Only field data counts. Google assesses the 75th percentile of real visits over 28 days, per URL group. Lab scores are for diagnosis, not for passing.
Fix by template, not by page. One slow header or one layout-shifting banner fails hundreds of URLs at once, and fixing it passes them at once.
Work in the order the metrics usually fail: Largest Contentful Paint first, then Interaction to Next Paint, then Cumulative Layout Shift. Most LCP failures are one image or one server.

In this article

Key takeaways
The three numbers and what passes
Read the right number first
Fix Largest Contentful Paint first
Then Interaction to Next Paint
Then Cumulative Layout Shift
What to stop spending time on
A routine that keeps it passing
The bottom line
FAQ
Sources

The three numbers and what passes

Core Web Vitals thresholds, assessed at the 75th percentile of field data

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	How long until the largest visible element has rendered. Usually the hero image or the headline.	2.5 s or less	2.5 to 4.0 s	Over 4.0 s
Interaction to Next Paint (INP)	How long the page takes to respond visually after a tap, click or key press, across the whole visit.	200 ms or less	200 to 500 ms	Over 500 ms
Cumulative Layout Shift (CLS)	How much visible content moves without the user causing it.	0.1 or less	0.1 to 0.25	Over 0.25

INP replaced First Input Delay as the responsiveness metric in March 2024. If a tool still reports FID, it is out of date.

A page passes when all three are good at the 75th percentile. That percentile is the point: three quarters of real visits must be good. One fast visit on your office connection tells you nothing, and neither does one slow visit on a tester's phone.

Read the right number first

There are two kinds of data and people confuse them constantly. Field data is collected from real Chrome users and is what Google uses. Lab data is a single simulated load on a single simulated device and is what most tools show you first.

Search Console, Core Web Vitals report. Field data, grouped by URL pattern, mobile and desktop separately. This is the report that decides whether you pass. Start here, and note which URL groups fail and on which metric.
PageSpeed Insights, the top section. Field data for one URL, plus the origin as a whole. If the URL has no field data, the origin number is your fallback and the page is probably too low-traffic to matter for this exercise.
PageSpeed Insights, the Lighthouse section. Lab data. Use it to find the cause once you know which metric fails. Do not use its score as the target.
Your own monitoring. If you run real-user monitoring, it is the best source, because it shows you the slow visits by device, connection and country. Field tools only show the percentile.

Fix Largest Contentful Paint first

LCP fails more often than the other two, and its causes are fewer. Nearly every failing LCP we see is one of four things, in roughly this order of frequency.

The largest element is an image that loads late
The hero image is lazy-loaded, or served at full resolution to a phone, or loaded by a script after the HTML. Put the image in the server HTML with fetchpriority="high", remove lazy loading from anything above the fold, serve a responsive size and a modern format, and preload it if it is a background image in CSS.
The server is slow to answer
Time to first byte over 800 ms leaves no room for anything else. Cache the HTML at the edge for pages that do not change per visitor. If the page is personalised, personalise after the first paint, not before it.
Render-blocking resources sit in the head
Stylesheets and synchronous scripts delay the first paint. Inline the critical CSS, defer the rest, and move every script that is not needed for first paint to defer or to the end of the body. Tag managers are the usual offender.
Fonts hold the text back
If the largest element is a headline, a web font that blocks rendering is your LCP. Use font-display: swap or optional, preload the one weight the headline uses, and subset the file.

Then Interaction to Next Paint

INP is about the main thread being busy when the user acts. It is the metric most affected by things marketing added, and the fix is usually subtraction.

Find the long tasks. In the browser's performance panel, record a load and an interaction, and look for tasks over 50 ms. The script names tell you who to talk to.
Audit third parties. Chat widgets, A/B testing scripts, session recorders, consent tools and analytics tags together often account for most of the main-thread time. Remove what nobody uses. Load the rest after the page is interactive.
Break up your own work. Handlers that do everything synchronously on click block the paint. Yield to the browser between steps, and render the visual response before the heavy work.
Hydration on frameworks. If the site is built on a client-rendered framework, large hydration tasks can hold INP hostage. Reduce what hydrates on first load; server-render what does not need interactivity.

Then Cumulative Layout Shift

CLS is the easiest to fix and the easiest to reintroduce. The causes are visual and you can see them with your own eyes by loading the page on a slow connection and watching.

Layout shift causes and fixes

What you see	Cause	Fix
Text jumps down when an image appears	Image without width and height attributes, so the browser reserved no space.	Set width and height, or an aspect ratio in CSS, on every image and embed.
Content jumps when a banner or cookie notice appears	The element is injected at the top of the flow after load.	Reserve the space, or position the element so it overlays instead of pushing.
Text changes shape or size as it loads	Web font swapped in after a fallback with different metrics.	Use a size-adjusted fallback font so the swap does not reflow, and preload the font.
Ad or widget slots expand	Third-party content with no reserved height.	Give every slot a fixed minimum height. If the height varies, pick the most common one.
The page shifts on interaction	A click opens an element above the current viewport, or a handler takes too long, so the shift is counted.	Open elements in place or below, and respond within 500 ms so the shift is attributed to the input.

What to stop spending time on

Chasing a Lighthouse score. The score is a lab composite. A site can score 60 and pass all three field metrics, and the reverse. Pass the field metrics, then stop.
Fixing pages one at a time. If the group fails, the template is at fault. Fixing twenty individual URLs changes nothing for the other two thousand in the group.
Micro-optimising scripts that are not on the critical path. Minifying a script that loads after interaction changes no metric. Look at what blocks the first paint and the first interaction, and ignore the rest.
Buying a plugin that promises a green score. Most of them defer everything, which improves lab numbers and breaks INP for real users when the deferred work lands all at once.
Treating it as a ranking campaign. Page experience is a small signal that mostly breaks ties. The reason to fix it is that slow pages convert worse and that a template-wide regression can take a whole section's rankings with it. Fix it for that, measure it for that.

A routine that keeps it passing

Weekly: glance at the Search Console report. A group turning orange within a week of a release tells you which release.
Every release: run a lab test on one page per money template, compare LCP and total blocking time to the previous release, and block the deploy if either doubled. This takes seconds when scripted.
Quarterly: repeat the third-party audit. Scripts accumulate the way furniture does.
When a group fails: open one URL from the group, read the field metric that fails, and work this guide's section for that metric. Do not start with the score.

The bottom line

Read field data at the 75th percentile, by URL group. That is what passes or fails.
Fix templates, in the order LCP, INP, CLS. One image, one slow server, one blocking script and one unreserved space account for most failures.
Stop chasing lab scores and individual pages. Put a per-release check in the deployment process and the problem stays fixed.

Frequently asked questions

Do Core Web Vitals affect rankings?: Yes, as a small signal within page experience, and mostly as a tie-breaker between otherwise similar pages. The larger effects are indirect: slow pages lose visitors before they convert, and a performance regression that hits a whole template can coincide with a ranking drop across that template.
Why does my page pass in Lighthouse but fail in Search Console?: Lighthouse is one simulated load. Search Console is the 75th percentile of real visits over 28 days, many of them on slower devices and connections than the simulation. The field data is the one that counts. Use the lab tool to find causes, not to declare victory.
How long after a fix does the report change?: Field data is a rolling 28-day window, so a fix shows fully after about four weeks, and partially from the first week. If nothing has moved after six weeks, the fix did not reach the visits that were slow, which usually means the wrong template or the wrong device class.
Should I fix desktop or mobile first?: Mobile, almost always. It fails more often, it is where most visits are on most sites, and the fixes carry over to desktop. The exception is a B2B site whose field data shows most visits and most failures on desktop.

How this guide was put together

Thresholds and definitions are taken from Google's web.dev documentation as of October 2026. The order of fixes reflects the frequency of causes across our audits; your site may differ, and the field data will tell you.

Sources

Jamal Oughia

Founder, Lucidens

Founder of Lucidens. A decade of organic-search practice across English-, French- and Arabic-speaking markets, with a particular interest in measurement and in how answer engines choose their sources.

How this connects to the Method