Core Web Vitals in 2026: what still moves rankings

Most conversations start with a red bar in PageSpeed Insights and the question of what a fix costs. That depends on whether field data exists at all, which templates are affected, and whether your content can compete with the results above you.

What follows is the order we work in and where we deliberately stop. Google wrote the explainer for LCP, INP and CLS in more depth than an agency can retell; it is linked below.

What Core Web Vitals actually decide

Google does not describe page experience as a single signal. Search Central documentation says the core ranking systems look at a variety of signals that align with overall page experience. Core Web Vitals are one of them.

Two sentences in the same document rarely make it into agency decks. Good results in the Search Console Core Web Vitals report do not guarantee that your pages will rank at the top. And chasing a perfect score for SEO reasons alone, in Google's own words, may not be the best use of your time. Asked how important page experience is to ranking success, the documentation answers that Search always seeks to show the most relevant content, even if the page experience is sub-par.

That gives you a usable rule of thumb. At position 30, LCP is almost certainly not the reason. At position 4, with the results above you comparable on substance, technical quality can decide it. Separately from Google, slow pages cost enquiries, and that part you can calculate in your own analytics.

The three metrics and what "good" means

Since 12 March 2024, Interaction to Next Paint (INP) has been a stable Core Web Vital, replacing First Input Delay. Chrome then removed FID; since 9 September 2024 its tools no longer serve FID data. A dashboard still running on FID has measured nothing for over a year.

Google's thresholds for "good":

The qualifier most summaries drop matters more than the numbers: measurement happens at the 75th percentile of page loads, segmented across mobile and desktop, and a page passes only when it holds all three thresholds there. Your own test on a MacBook over office wifi is not a measurement, just a data point from the comfortable end of the distribution.

Field data or lab data

Field data comes from the Chrome User Experience Report (CrUX): real Chrome users, aggregated over 28 days. PageSpeed Insights, the Search Console report and the CrUX API all draw from it. Lab data comes from Lighthouse: one device, one network profile, one run. Reproducible and good for debugging, but a simulation.

Lighthouse cannot measure INP. Without a real user interaction there is no INP value; that is a property of the metric, not a gap in the tool. Total Blocking Time stands in for it in the lab. A green TBT alongside poor INP is the normal case, not a contradiction.

Many pages have no field data at all. CrUX only includes a page if it is indexable and reaches a minimum number of visitors. Google does not publish the threshold. Low-traffic pages may therefore have no page-level data even when the origin is eligible. In that case, work with origin-level data or measure directly with Google's web-vitals library and send the values to your analytics.

CrUX does not see everything. Chrome on iOS, Android WebViews and other Chromium browsers such as Edge contribute nothing. Query parameters and fragments are stripped from URLs, so all variants collapse into one value. For shops with filter URLs that surprises people.

Where lab and field disagree, field wins. Chrome's own documentation says so.

The order we work in

Nobody pays to have 40 Lighthouse hints ticked off in sequence. Our sequence for technical on-page work:

1. Field data before the first change. If none exists, install RUM and collect for two weeks. Without a baseline you cannot later show what the work achieved.
2. Aggregate by template, not by URL. Home, service page, category, product, article. A template fix reaches a thousand URLs; a URL fix reaches one. Google assesses page by page, but you repair the template.
3. Prioritise by business value, not by score. The template that produces enquiries goes first, even if another looks worse.
4. LCP first, in this sequence: identify the LCP element, check whether its URL is discoverable in the HTML source, set priority (fetchpriority="high", remove loading="lazy" from the LCP image), then TTFB and CDN, and only then file size. Per Chrome's real-user analysis, most origins with poor LCP spend under 10% of their p75 LCP time downloading the image. The time goes earlier.
5. CLS next, because it is usually cheap: width and height or aspect-ratio on anything that loads late. A sensible min-height instead of the default 0px on containers whose content arrives later. No animation of layout-inducing properties; use transform. Then check bfcache eligibility, which also helps LCP.
6. INP last, and only with field diagnostics. Break up long tasks (anything over 50 milliseconds), remove unnecessary JavaScript, avoid large rendering updates. The tag manager container belongs on the table here, because that is where the scripts nobody owns tend to live.
7. Wait 28 days. The CrUX window rolls, so a fix shows up first as a flat improvement and is fully visible only after four weeks.

Step 7 is where projects fail, because after ten days someone asks why nothing has moved.

What we deliberately skip

We do not chase a Lighthouse score of 100. That score is a weighted lab value, not a ranking signal.

We do not start with image compression while the LCP image is discovered only after JavaScript runs. A smaller image that starts late is still late.

And we do not optimise templates with neither field data nor commercial value. A relaunch is different: there the numbers belong in the acceptance criteria, otherwise the problem simply moves, as it does during a migration more often than clients expect.

When Core Web Vitals are not your problem

If your page does not appear in the top 20 for the queries that matter to you, an LCP of 2.1 instead of 3.4 seconds changes nothing. What is missing is content, relevance or authority, and the engineering hours are better spent making your pages unambiguous to search engines and AI systems: Structured data that produces real rich results.

If your numbers are green and the rankings still do not come, you have cleanly ruled out one cause. That is also a result.

---

Whether technical work is your bottleneck is what the free analysis tells you.