Core Web Vitals: Do They Affect SEO, and How to Improve Them

Core Web Vitals are three Google metrics for how a page feels to real visitors. Largest Contentful Paint (LCP) times the main content. Interaction to Next Paint (INP) times the response to taps and clicks. Cumulative Layout Shift (CLS) measures how much the layout jumps.

Do they affect SEO? Yes, but less than many speed guides suggest. Google says Core Web Vitals are used by its ranking systems, yet it still ranks the most relevant page first. Speed pays off more in sales, because visitors who wait tend to leave.

I cover the targets, what Google says about rankings, and the conversion studies I could verify. Then I show the fix order I used on this site in October 2026, including a page that got slower.

What Core Web Vitals measure, and the scores to aim for

Google’s Core Web Vitals documentation calls them “a set of metrics that measure real-world user experience.” Each one has a “good” threshold. Google’s web.dev pages for LCP, INP and CLS give the full bands.

Each metric is judged at the 75th percentile of page loads, “segmented across mobile and desktop devices,” as web.dev explains. In plain terms, at least three visits in four must hit the good mark. A fast page on your office Wi-Fi counts for little if most visitors use a mid-range phone on mobile data.

INP replaced First Input Delay (FID) on 12 March 2024. In early 2024, Google’s web.dev team wrote that “INP will officially become a Core Web Vital and replace FID on March 12 of this year.” INP assesses a page’s “overall responsiveness to user interactions,” watching clicks, taps and key presses during the visit. If a guide still tells you to fix FID, it is out of date. The earlier version of this page did exactly that.

Field data vs lab data: your PageSpeed score is not your Core Web Vitals

Google judges Core Web Vitals on field data: timings from real Chrome users, collected in the Chrome UX Report (CrUX). Lab data comes from a test on a simulated device and network. Web.dev’s guide to why lab and field data differ says they “actually measure very different things.”

Field data is a rolling window. As that guide puts it, “CrUX reports show a distribution of performance metrics from real Chrome users over a 28-day period.” Search Console’s Core Web Vitals report uses the same CrUX data. So a fix you ship today takes about four weeks to show in full.

PageSpeed Insights shows both: field data when Google has it, and a Lighthouse lab test. The lab test gives the 0 to 100 Performance score: 90 or above is good, 50 to 89 needs improvement, and below 50 is poor. PageSpeed Insights is one of the free Google tools I rely on most. But its score is a debugging aid, not your Core Web Vitals.

A lab test also cannot measure INP, because nobody taps the page. It reports Total Blocking Time (TBT) instead. Web.dev says TBT “may be a reasonable proxy metric for INP for the lab” but is not a substitute for INP.

Many small business sites have no field data at all. CrUX only includes sites and pages that are “publicly discoverable” and “sufficiently popular,” and Google does not disclose the cut-off. Only some Chrome users contribute, and Chrome on iPhone does not. Without enough data, Search Console shows “No data available” or leaves the URL out.

This site is one of them. ujjwalganesh.com does not get enough Chrome traffic for CrUX, so its Core Web Vitals report in Search Console is empty. Every number I share below is a mobile lab score from PageSpeed Insights.

Do Core Web Vitals affect SEO? What Google actually says

Yes, modestly. Google’s page experience documentation is direct: “Core Web Vitals are used by our ranking systems.” It is just as direct about the limits:

• “There is no single signal.” Google’s core ranking systems look at a variety of signals that align with page experience.
• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.”
• “But for many queries, there is lots of helpful content available.” In those cases, Google says, a great page experience can help.
• Getting good results in Search Console or third-party tools “doesn’t guarantee that your pages will rank at the top of Google Search results.”

Google adds that “trying to get a perfect score just for SEO reasons may not be the best use of your time.” I agree. Get every page type into the good range, then spend the time on your content and on why visitors are not converting. Google’s guide to its ranking systems does not list page experience as a separate system.

Did AI make Core Web Vitals a bigger ranking factor?

The earlier version of this article was titled “The AI Effect: How Core Web Vitals Now Directly Impact Your Rank.” That overstated it. None of Google’s page experience, Core Web Vitals or ranking systems pages says AI has made them a bigger factor.

Google’s AI features guide says: “There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.” Its list of normal SEO best practices includes “Providing a great page experience for users.” So the same rules apply. I cover the rest in my guide to AI Mode in Google Search.

Dan Taylor, head of technical SEO at SALT.agency, tested this. He analyzed 107,352 pages that appear prominently in Google AI Overviews and AI Mode. Slower pages did slightly worse. “For Largest Contentful Paint, the correlation ranged from -0.12 to -0.18.” For CLS, it was “typically between -0.05 and -0.09.”

In his words, these relationships “are not strong in practical terms.” The exception was the slowest pages: those “in the extreme tail of CWV performance, particularly for LCP, were far less likely to perform well.” His conclusion: “Core Web Vitals are therefore best understood as a gate, not a signal of excellence.”

Two cautions. It is a correlation study, so it cannot prove that speed caused the difference. And it does not report INP. Still, it matches Google’s own line: fix pages that are very slow, and do not expect a perfect score to lift you above better content.

Website speed and conversion rate: what the evidence says

Speed matters more for sales than for rankings. In my book Decoding The Click, I put it this way: “A website that is clear but slow is a promise unfulfilled.” The page shows visitors where to go, then makes the trip a crawl.

This is also why I disagree with the advice to optimize for Google first and let the user experience follow. With speed, it works the other way round. Make the page fast for a visitor on a slow phone, and you have done what Google’s scores are there to encourage.

The old “3-second rule” comes from a 2017 Google figure. Google’s Daniel An wrote that “53% of mobile site visitors leave a page that takes longer than three seconds to load,” citing Google/SOASTA Research, 2017. That data is years old, and phones and networks have changed. Treat it as a direction, not a law.

Stronger evidence comes from studies that measured sales:

• Milliseconds Make Millions. This study was commissioned by Google and run by 55 and Deloitte. It covered 37 leading European and American brand sites and over 30 million user sessions. It found that “a 0.1 second improvement of mobile site speed increases conversion rates by 8.4% for retail sites and 10.1% for travel sites.” Retail shoppers also spent 9.2% more.
• Vodafone. In an A/B test on a landing page, “a 31% improvement in LCP led to 8% more sales.” An A/B test is stronger evidence than a correlation, because both versions ran at the same time.
• The Economic Times. The Indian news site cut its LCP from 4.5 to 2.5 seconds and its CLS from 0.25 to 0.09. It “reduced bounce rates by 43% overall.”
• redBus. The Indian bus-ticketing site worked on INP, and Google’s case study reports “a 7% overall increase in sales.”

Keep these in proportion. They are large brands, and Google chose which case studies to publish. A small service business should not expect the same percentages. But every one of them points the same way.

One figure you will see everywhere says a one-second delay cuts conversions by 7%. I could not find its original study online, so I have left it out. The same goes for several numbers in the two older posts this page replaces.

My own site: from 61 to 97, and back to 81

In October 2026, I audited this site, ujjwalganesh.com. It runs WordPress with an Elementor-based theme, on Hostinger shared hosting with a LiteSpeed server. On 28 October, the homepage scored 61 in a mobile lab test on PageSpeed Insights. LCP was 6.0 seconds, TBT was 510 ms, and the page weighed 4.5 MB.

The audit found five causes:

• No page caching. The LiteSpeed Cache plugin was installed but not active.
• Oversized JPEG images. The book cover was 1000 × 1520 px but shown at 400 px wide.
• Render-blocking CSS from many small Elementor stylesheets.
• 356 KiB of unused JavaScript: jQuery, Swiper, the emoji script, and analytics and a pixel on every page.
• A looping carousel that cloned its slides.

Here is what each change did, in lab tests on mobile:

Caching and the PHP update together took the homepage from 61 to 91. The PHP update was part of the same evening’s security work, which I describe in my WordPress security checklist.

The surprise was the article page. Its score fell from 87 to 75 after the same change. Its 1,500 px featured image became the largest element on the screen, and LCP rose to 5.2 seconds. Caching fixes server time, not image weight. The lesson: re-test every page type after each change, not just the homepage.

The second surprise came a day later. After new templates on 1 November, the homepage scored 97. By 2 November, after more features had gone live, a re-test gave 81, with LCP at 4.3 seconds. PageSpeed Insights now flags render-blocking requests and image delivery as the biggest savings. Speed is not a one-time fix. Every new script, form and image is a fresh chance to slow the page down.

One honest limit. These are lab tests, and there is no field data for this site. So I cannot tell you what real visitors experienced, or show a ranking or sales change from this work.

How to improve Core Web Vitals on a WordPress site

This is the order I would follow on most WordPress sites. The early steps are cheap and fix many pages at once.

1. Turn on page caching

Without a page cache, WordPress builds each page on every visit. Check that caching is actually active, not just installed, as mine was not. If the server is still slow with caching on, look at hosting and a CDN, which web.dev recommends for faster server response. I compare hosts in my guide to cloud and hosting providers in India.

2. Fix the LCP element on each page type

First find out which element it is. Lighthouse, the lab test inside PageSpeed Insights, names it under “Largest Contentful Paint element”. It is often an image. Serve that image at the size it is shown, compressed. My book cover was more than twice its display width.

Then make sure the browser loads it early. Web.dev’s guide to the most effective fixes says to “Remove the loading="lazy" attribute from the <img> tag of your LCP image” and to add fetchpriority="high". WordPress 6.3 and later try to do this for you. Check the page source anyway, especially with a page builder.

3. Cut render-blocking CSS and unused JavaScript

Load sliders, galleries and their scripts only on pages that use them. Drop the emoji script if you do not need it. Ask whether every page really needs every tracking pixel. As web.dev puts it, “When you ship too much JavaScript, you’re creating an environment where tasks are competing for the main thread’s attention.”

4. Replace heavy carousels

A carousel adds script and extra markup, and mine cloned its slides. A single static image with one clear message is usually lighter, and often clearer.

5. Reserve space so nothing jumps

For CLS, web.dev says “the best way to fix layout shifts caused by unsized images is to explicitly set width and height attributes.” Do the same for video. Reserve fixed space for ads and embeds, which can resize themselves after load.

6. Keep the main thread free for taps

For INP, the same web.dev guide says to “Yield often to break up long tasks” and “Avoid unnecessary JavaScript.” On WordPress, that usually means fewer plugins and third-party widgets adding scripts. In the lab, watch TBT; web.dev suggests keeping it under 200 ms. My homepage went from 510 ms to 80 ms.

Test every page type, on a real phone

A fix that helps one template can hurt another, as my article page showed. After each change, re-test your homepage, a service or product page, and an article. Run each test two or three times. The Lighthouse scoring guide notes that “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.”

Then test on a real phone. In my checklist for choosing a UI/UX design agency in India, I tell buyers to ask one question about this. “Do you test the live site on a sub fifteen thousand rupee Android device on a slow 4G connection before sign off?” Ask your own developer the same.

If you do have field data, use it. After fixing an issue in Search Console’s Core Web Vitals report, click Start Tracking. That begins “a 28-day monitoring session.” Sites also slow down again as plugins, scripts and large images pile up. Re-test after every new plugin or redesign.

Where to start this week

Run PageSpeed Insights on mobile for three pages: your homepage, your main service or product page, and an article. For each, note the LCP element, the LCP time and TBT, and whether any field data exists. Confirm a page cache is on, fix the LCP image, and test all three again.

If you would like a second opinion, my website SEO audit covers speed and Core Web Vitals alongside crawling, indexing and content. Every problem is ranked by what it costs you, so your developer knows what to fix first.