Core Web Vitals: How Site Speed Affects Google Rankings

Core Web Vitals are three metrics Google uses to describe real-world page experience: LCP (how fast the main content appears), INP (how fast the page reacts to a click or tap) and CLS (how much content jumps around while loading). Google says they are used by its ranking systems, but they do not replace content relevance.

The good news is that the thresholds are clear and most problems have repeatable causes: a large image loaded late, third-party scripts, missing image dimensions. The less good news is that many people optimize for the wrong score. This guide shows what to measure, where to read real-user data and what to fix, in order of impact. Speed work is one of the central parts of technical SEO, and for a quick check you can use our site speed test.

What are the three metrics, and what are their thresholds?

Each metric has three zones: good, needs improvement and poor. Google assesses a page, or a group of similar pages, at the 75th percentile of real visits, separately for mobile and desktop. In other words, three out of four visits must fall within the good threshold.

A few clarifications to avoid confusion:

• LCP usually refers to an image, a video poster or a large block of text. On many pages it is the photo at the top.
• INP replaced FID as a Core Web Vital in March 2024. Unlike FID, it looks at interactions across the whole visit, not just the first.
• CLS is not measured in seconds. It is a unitless score: the more elements shift, and the farther they move, the higher it climbs.

One useful related term is TTFB (time to first byte). It is not one of the three metrics, but it feeds directly into LCP: if the server answers slowly, everything else starts late.

How much do Core Web Vitals affect Google rankings?

Google’s documentation says that Core Web Vitals are used by its ranking systems, and that good scores do not guarantee a top position. It also says Search always seeks to show the most relevant content, even when page experience is sub-par. In short: a fast site will not outrank a far more relevant one, but when content is similarly helpful, a great page experience can contribute to success.

Think of the effect in two layers:

1. The direct ranking effect is modest and hard to isolate. Nobody can promise that moving from red to green will lift a page by a position.
2. The indirect effect is often bigger. A slow page loses visitors before it loads, sees more abandonment and converts less. That shows up in revenue even if rankings stay put.

So treat speed as an investment in conversions and crawling, not as a ranking trick. Equally, strong content on a page that jumps and lags never reaches its potential. For that content side, see our guide to E-E-A-T.

Field data or lab data: which one should you read?

This is where most confusion starts. There are two kinds of data:

• Field data: measured on real users in Chrome, aggregated over 28 days. It comes from the Chrome UX Report (CrUX) and appears in Search Console and at the top of PageSpeed Insights. This is the data that matters to Google.
• Lab data: a synthetic test, run once on a simulated device and network (Lighthouse). It is great for diagnosis because it is repeatable, but it does not reflect the diversity of real users.

The practical consequence: Lighthouse in its standard mode cannot measure INP, because a simulated page load contains no real user interactions. In the lab you see an approximation, Total Blocking Time. That is why a superb lab score can coexist with a poor field INP.

Where to look:

1. Search Console, Core Web Vitals report. It shows the status of groups of similar pages, split by mobile and desktop. A group’s status is set by its weakest metric. The report appears only when there is enough data. How to read the console is covered in our Search Console beginner’s guide.
2. PageSpeed Insights. For one URL it shows field data (if available) and the lab test, with recommendations.
3. Your own measurements. The web-vitals JavaScript library reports the actual values your users experience:

import { onLCP, onINP, onCLS } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name, value: metric.value, id: metric.id
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

If your traffic is low, your own measurements may be the only field data you get.

How do you improve LCP?

LCP breaks down into four phases, and knowing which one is costing you saves hours of guessing. The web.dev guidance suggests a rough split, which it describes as a guideline and not a strict rule:

1. TTFB, around 40% of the total: how quickly the server responds.
2. Resource load delay, under 10%: the time before the browser starts downloading the LCP image.
3. Resource load duration, around 40%: file size and format.
4. Element render delay, under 10%: the time until the element is actually painted.

The two “delay” phases should approach zero. If they are large, the problem is not the image itself but how you load it. The fixes, in order:

1. Identify the LCP element. Chrome DevTools (Performance panel) or Lighthouse names it explicitly. You optimize what counts, not every image.
2. Never put loading="lazy" on the LCP image. It is a common mistake, especially in themes that defer all images. The main image must load right away.
3. Set priority. The fetchpriority="high" attribute on the likely LCP image helps the browser request it sooner:

<img src="/img/hero.webp" width="1200" height="630"
     alt="Short description of the image" fetchpriority="high">

1. Cut the image weight. Use a modern format (WebP or AVIF), sizes that match the screen and sensible compression. Details in our guide to image SEO.
2. Improve TTFB. Page-level caching, hosting that is not overloaded, a CDN for static files and fewer database queries. On WordPress, the essential settings include caching.
3. Remove render-blocking CSS and JavaScript. Inline only the CSS needed for the visible part and defer the rest.

How do you improve INP?

INP rises when the page is busy and cannot respond to a tap. The culprit is usually long-running JavaScript on the main thread. Any task over 50 ms can block interactions.

• Reduce the amount of JavaScript. Plugins, chat widgets, trackers, sliders and effect-heavy themes are paid for on every visit. Remove what does not earn revenue or inform users.
• Break up long tasks. Hand control back to the browser between operations so it can react:

button.addEventListener('click', async () => {
  updateInterface();                          // immediate visual response
  await new Promise(r => setTimeout(r, 0));   // yield the main thread
  heavyCalculation();                         // the rest of the work
});

• Defer third-party scripts. Load them after the first interaction or with a delay, wherever they do not affect the page’s function.
• Keep the DOM reasonable. Pages with thousands of elements slow down every style recalculation.
• Watch JavaScript-built sites. If the interface is assembled in the browser, responsiveness and indexing depend on the same code; see JavaScript SEO.

How do you improve CLS?

CLS is the easiest metric to fix because the causes are few and predictable:

• Images and iframes without dimensions. Add width and height attributes or the CSS aspect-ratio property so the browser reserves space before the download.
• Banners, ads and widgets injected late. Reserve a container with a fixed height from the start.
• Web fonts. Swapping from the fallback font to the final one shifts text. Use font-display: swap, host fonts locally, preload the main one and pick a fallback with similar metrics:

@font-face {
  font-family: "Headline";
  src: url("/fonts/headline.woff2") format("woff2");
  font-display: swap;
}

• Content inserted above existing content. Cookie banners or promo messages that push the page down after it loads. Show them as overlays or with reserved space.
• Animations that change dimensions. Prefer transform and opacity, which do not trigger layout shifts.

Common Core Web Vitals mistakes

• Relying on one lab test. Run it several times and compare with field data.
• Optimizing only the homepage. Search Console assesses groups of pages; products, articles or categories can be red even if the homepage is green.
• Measuring only on desktop. Mobile is the hard case, and Google uses mobile-first indexing.
• Deferring every image. Lazy loading the LCP image slows the exact metric you are trying to fix.
• Stacking one “optimization” plugin on another. Several cache or minification plugins can fight each other.
• Ignoring third-party scripts. A tag added by marketing can wreck INP without any visible change in your code.
• Stopping after one fix. After changes, field data takes about 28 days to catch up, so you verify over time.

When Core Web Vitals are not your priority

Honesty helps here: not every page needs the same attention.

• If a page does not appear in Google at all, speed is not the cause. Check indexing first.
• If your metrics are already green, pushing them lower yields little. Put the effort into content and links instead.
• A new site with few visits lacks enough field data. Do not draw conclusions from a single isolated test.
• A highly relevant site can hold good positions with mediocre metrics, which is still no reason to ignore users waiting on a slow page.

For an online store, where every second on mobile shows up as abandoned carts, the priority is higher; the context is discussed in our ecommerce SEO guide. The same logic applies to any business whose customers browse mostly on phones.

Conclusion and next steps

Core Web Vitals are not a goal in themselves but a way to check real experience. A simple plan:

1. Open the Core Web Vitals report in Search Console and note the red and orange page groups, on mobile.
2. Pick the highest-traffic page from one group and run PageSpeed Insights; read the field section first, then the lab section.
3. Fix in this order: the LCP image, media dimensions, unnecessary scripts.
4. Add web-vitals measurement if field data is missing.
5. Recheck after about 28 days, not the next day.

If you would rather have a team run the checks and the fixes, start with our technical SEO service or write to us via the contact page.