Do Core Web Vitals Affect Rankings? An Honest Answer

Yes, Core Web Vitals affect rankings, and the effect is much smaller than the industry sells it. Google's page experience documentation says two things in the same breath: "Core Web Vitals are used by our ranking systems", and "Google Search always seeks to show the most relevant content, even if the page experience is sub-par". Both halves are true. The second half is the one that gets cut from the pitch deck.

The useful way to think about Core Web Vitals SEO impact is as a tiebreaker. When several pages are comparably helpful, page experience can separate them. When one page is clearly the better answer, being slow does not stop it winning. That is why you can search almost any competitive query and find a page loading in five seconds sitting at position one.

What Google actually says, in full

The documentation is unusually blunt for Google. Alongside the confirmation that the metrics feed ranking systems, it notes that "for many queries, there is lots of helpful content available" and that "having a great page experience can contribute to success in Search, in such cases". It also warns directly that achieving perfect scores "for SEO reasons may not be the best use of your time".

Read that as a hierarchy. Relevance first. Content quality second. Links and authority alongside. Page experience somewhere after all of it, mattering most when the preceding factors are close to level.

Anyone telling you a Lighthouse score of 100 will lift you from page two to page one is describing a causal chain nobody has demonstrated. The honest claim is narrower: slow pages lose ground they might otherwise have held, and the loss is hard to isolate from everything else moving at the same time.

The three metrics, concretely

Core Web Vitals are assessed at the 75th percentile of real page loads, segmented across mobile and desktop. That percentile matters more than people realise. Your median user experience can be fine while a quarter of your traffic has a bad time, and it is that quarter the assessment reflects.

LCP is usually an architecture problem

Largest Contentful Paint is the time until the biggest above-the-fold element renders. On most marketing pages that element is the hero image or the hero heading.

The failures we see are almost never "the image is too big". They are structural: the LCP element is hidden behind something, or is not in the server-rendered HTML at all, or is waiting on a font, or sits behind a render-blocking script that has nothing to do with it. A page can ship a 40 KB hero image and still post a four-second LCP because the element carrying it does not exist until JavaScript has hydrated. On a hosted builder you often cannot reach that decision at all, which is one of the limits worth knowing before you choose a platform.

INP is the one nobody writes about properly

Interaction to Next Paint replaced First Input Delay on 12 March 2024, and the coverage never caught up. Most articles still explain the three vitals as "loading, interactivity, visual stability" with a paragraph on FID that is two years out of date.

The difference matters. FID measured only the delay before the first interaction's handler started running, which flattered almost everybody — you could pass FID comfortably while every click on the page felt like treacle. INP measures the latency of all click, tap and keyboard interactions across the whole visit, from the moment the user acts until the next frame paints. It is much harder to pass by accident.

An interaction breaks into three parts:

1. Input delay — the main thread is busy with something else, so your event handler cannot start. Usually third-party scripts, hydration, or analytics.
2. Processing duration — your own event callbacks running. Long list re-renders, expensive state updates, synchronous work that should have been deferred.
3. Presentation delay — the browser producing the next frame. Large DOM, expensive layout, heavy style recalculation.

The practical implications are unglamorous. Ship less JavaScript. Break long tasks up and yield to the main thread between chunks. Do not run a full re-render on every keystroke. Be suspicious of any third-party tag manager container that has grown organically for three years. On React, an accordion or filter that re-renders a two-thousand-node subtree on click is a classic INP failure that no image optimisation will touch.

INP is also the vital most likely to be bad on a site that scores well in Lighthouse, because a synthetic run does not click anything.

CLS is the cheapest to fix and the most annoying to leave

Cumulative Layout Shift measures content moving while someone is trying to read or tap it. Causes are boringly consistent: images and embeds without dimensions, web fonts swapping and reflowing text, cookie banners and promotional bars injected above existing content, and elements animated with top or height rather than transform.

Every one of those has a known fix. Set explicit width and height (or aspect-ratio) on every image and iframe. Reserve space for anything injected late. Animate transform and opacity only. CLS is usually an afternoon of work, which makes leaving it broken hard to justify on any grounds.

Lab versus field, and why your two tools disagree

This is the single most common source of confusion, and it is not a bug in either tool.

Lab data is Lighthouse, PageSpeed Insights' top section, and your local DevTools run. One synthetic page load, on a simulated device, over a throttled connection, in a controlled environment. It is repeatable and diagnostic — it tells you what is slow and why.

Field data is the Chrome User Experience Report, which reflects how real Chrome users actually experienced your pages. It is what Search Console's Core Web Vitals report shows, and it is what Google uses. It is aggregated over a trailing window, so it lags your deployments by weeks.

They disagree for structural reasons:

Three practical consequences. A perfect lab score with failing field data usually means your real audience is on worse hardware or worse connections than the simulation, or that interaction cost only shows up with real users. Failing lab data with passing field data usually means the throttled simulation is harsher than your audience's reality. And after a fix ships, the field data will not move for weeks, so do not judge the change by refreshing Search Console the next morning.

If a page has too little traffic for CrUX, you get no field data at all and lab data is all you have. That is a reason to instrument your own real-user monitoring rather than a reason to trust Lighthouse more.

What we fixed on this site

Two things on devfinix.com made a good LCP structurally impossible, and both are the kind of fault that a design review approves and a performance review never sees.

The first was a full-screen loading overlay. A PageLoader component covered the viewport for roughly two and a half seconds on every page load, including repeat visits. It looked deliberate. What it actually did was guarantee that the largest contentful paint could not happen until the overlay cleared, because for that whole period there was nothing else to paint. No amount of image optimisation can rescue a page that is voluntarily showing a blank screen. We deleted it.

The second was subtler. The hero <h1> — the LCP element on the homepage — shipped with an opacity: 0 initial state, waiting for Framer Motion to hydrate and fade it in. Server-side rendering was working perfectly. The text was in the HTML. The browser had everything it needed to paint the largest text on the page immediately, and it could not, because CSS said the element was invisible until JavaScript ran. The fix is to animate transform only and never opacity on the LCP element. It is now guarded by a unit test, because it is exactly the kind of thing that gets reintroduced by someone adding a nice entrance animation. The same disagreement between the rendered page and the delivered HTML quietly breaks structured data too, which is the subject of schema markup for AI search.

We also gave the hero video a poster image and set preload="none". The video is around 8 MB. Previously it began streaming on load, competing for bandwidth with everything that mattered. The poster is roughly 92 KB, paints immediately, and the video downloads only when it is actually going to play.

Sites that never take on that weight have less to fix in the first place. The LiquidChain landing page ships around 17 KB of HTML with no trackers, and the Arash Rezaei site runs a self-only content security policy with none either.

We are not publishing before-and-after Lighthouse numbers, because we did not measure them under controlled conditions and inventing them would be worse than saying nothing. What we can say is that all three were structural defects: the page could not have performed well regardless of hosting, image formats or caching, because it was actively preventing itself from painting.

That is the general lesson. Most genuinely bad LCP is not a tuning problem. It is something in the build actively blocking the paint.

Where Core Web Vitals genuinely pay off

If the ranking benefit is modest, why do the work at all? Because two other effects are more reliable than the ranking effect.

Conversion. The relationship between speed and abandonment is not controversial, and unlike rankings you can measure it yourself with your own analytics. A checkout or enquiry form that responds slowly to taps loses people. INP is the vital most directly tied to this, because it measures the moment a user does something and waits. You do not need an industry statistic to justify this; run the comparison on your own funnel.

Crawl efficiency. A site that responds slowly gets crawled less productively. This matters little for a fifty-page brochure site and considerably for a large ecommerce catalogue where new and updated products compete for crawl attention. It is one of the reasons performance turns up as a real issue during store migrations, where thousands of URLs need recrawling in a compressed window.

Everything downstream of relevance. Here is the version worth internalising: Core Web Vitals do not make a weak page rank. They stop a strong page being handicapped. If you have done the content and earned the links, it is cheap and sensible not to hand back part of that advantage. If you have not, fixing CLS will not save you.

How to decide whether it is worth a sprint

A rough order of operations that has held up across client work:

1. Check field data first. Search Console's Core Web Vitals report, not Lighthouse. If your URL groups are green, stop. There is no ranking upside in moving from good to slightly better, and Google says as much.
2. If a group is failing, find out which metric and which template. Failures cluster by page type — all product pages, all blog articles — because they share a component.
3. Look for a structural blocker before tuning. Full-screen loaders, opacity: 0 on the LCP element, client-only rendering of above-the-fold content, a 5 MB media file on the critical path. These are single fixes with large effects, and the client-rendering one also hides your content from AI crawlers that do not run JavaScript.
4. Then do the boring wins. Image dimensions, font display, third-party script audit, deferring anything not needed for first paint. On WordPress this is nearly always a plugin problem rather than a platform one, which is part of the case against re-architecting to headless.
5. Re-measure in the field after several weeks. Lab data confirms the fix landed. Field data confirms it mattered.

If you are choosing between a month on performance and a month on content, and your field data is not failing, choose the content. That is not an argument against performance work in a build, where it costs nearly nothing to do properly from the start. It is an argument against retrofitting performance as an SEO tactic when the actual gap is that your pages do not answer the query as well as the pages above you.

The decision rule

Treat Core Web Vitals as hygiene, not strategy. Fix them because a fast site converts better and because failing them is a self-inflicted handicap, not because you expect positions to move. Prioritise INP, which is both the newest vital and the one most likely to be quietly failing while your Lighthouse score looks excellent. Trust field data over lab data for judging whether you have a problem, and lab data over field data for working out what it is.

If someone quotes you a ranking improvement from a performance engagement, ask how they intend to isolate it from every other variable in play. The answer to that question tells you most of what you need to know about the rest of the proposal. When we run technical SEO work, speed sits in the hygiene column with crawlability and structured data — necessary, unglamorous, and not the thing that wins the query on its own.