Core Web Vitals Explained: What They Mean for SEO

Your developer says the site is “fast enough.” Search Console disagrees and flags dozens of URLs as “Poor.” And a marketing agency is telling you that Core Web Vitals are why your rankings slipped.

Who is right? Usually, all of them a little. Core Web Vitals are 3 specific measurements Google uses to judge how a page feels to real visitors: how quickly the main content shows up, how fast the page reacts when someone taps or clicks, and whether things jump around while it loads. They do feed into Google’s ranking systems, but they are not a magic lever.

This guide explains each metric in plain English, the thresholds you need to hit, how to test your own pages, and the fixes that solve most problems on small business sites.

What Core Web Vitals are

Core Web Vitals are part of Google’s Web Vitals program, a set of quality signals for user experience on the web. The current set has 3 stable metrics:

Two details matter more than most people realize:

• Google grades the 75th percentile. A page passes when at least 75% of real visits meet the “good” target for all 3 metrics, measured separately for mobile and desktop. A fast experience on your office Wi-Fi does not count for much if most customers visit on older phones.
• The metrics can change, slowly. Google’s lifecycle rules say stable Core Web Vitals change no more than once a year. The last swap happened on March 12, 2024, when INP replaced First Input Delay (FID), which only measured the first interaction on a page.

Do Core Web Vitals affect SEO rankings?

Yes, but modestly. Google states that Core Web Vitals are used by its ranking systems and recommends that site owners achieve good scores. It also says there is no single page experience signal, and that it will still show the most relevant content even when the page experience is weak.

In practice:

• Content and relevance come first. A slow page that answers the question well can outrank a fast page that doesn’t.
• Vitals help most in close races. Google says good page experience matters most when there are many helpful results for a query, which describes most competitive local and ecommerce searches.
• The business case is bigger than rankings. Faster, more stable pages are easier to use, which tends to help conversions regardless of what Google does.

Google’s ranking systems generally assess pages individually, with some site-wide signals. So fixing your highest-traffic templates (home page, service pages, product pages) usually matters more than chasing a perfect score on every URL.

Key takeaway: Treat Core Web Vitals as a tiebreaker for rankings and a direct lever for conversions. Get your important templates into the “good” range, then put your energy back into content.

Largest Contentful Paint (LCP): loading speed

LCP marks the moment the largest visible element in the viewport finishes rendering. On most business sites that is a hero image, a banner, a product photo or a large headline.

Common causes of a slow LCP:

• Huge, uncompressed hero images or sliders
• Slow server response, often from cheap shared hosting or no caching
• Render-blocking CSS and JavaScript that must load before anything appears
• The main image being lazy-loaded, so the browser waits to fetch it
• Web fonts that delay text rendering

Most common fixes:

1. Compress and resize images, and serve modern formats such as WebP or AVIF.
2. Do not lazy-load the main above-the-fold image. Lazy-load images further down the page instead.
3. Add page caching and a content delivery network (CDN).
4. Remove or defer scripts and plugins that are not needed on first load.
5. Replace image sliders with a single static hero image.

Interaction to Next Paint (INP): responsiveness

INP measures how quickly the page visibly responds after someone clicks, taps or presses a key. It looks across all of those interactions during a visit and reports one of the slowest. Hovering, scrolling and zooming are not counted.

A poor INP feels like a menu that lags, an “Add to cart” button that does nothing for a moment, or a form field that stutters while typing.

Common causes:

• Heavy JavaScript running on the main thread
• Too many third-party scripts: chat widgets, tag managers, ad and tracking pixels, review widgets
• Page builders and themes that load large frameworks on every page
• Very large pages with thousands of HTML elements

Most common fixes:

1. Audit third-party tags and remove anything nobody uses.
2. Load chat and review widgets only after the page is interactive, or on user action.
3. Break up long JavaScript tasks so the browser can respond between them (a developer task).
4. Choose lighter themes and fewer plugins, especially on WordPress and ecommerce platforms.

Cumulative Layout Shift (CLS): visual stability

CLS adds up unexpected movements of visible content. If you have ever tapped a link just as an ad pushed it down the page, you have experienced a layout shift.

Shifts that happen within 500 milliseconds of a click, tap or key press are excluded, because the user expected something to change. Scrolling does not count as that kind of input.

Common causes:

• Images and videos without width and height set
• Ads, embeds and iframes that resize after loading
• Cookie banners or promo bars injected at the top of the page
• Web fonts that swap in and change text size

Most common fixes:

1. Set width and height (or an aspect ratio) on every image and video.
2. Reserve space for ads, embeds and banners with a fixed-size container.
3. Show announcement bars and cookie notices as overlays rather than pushing content down.
4. Preload key fonts and choose fallback fonts with similar sizing.

How to test your Core Web Vitals

There are 2 kinds of data, and you need to know which one you are looking at.

• Field data comes from real Chrome users through the Chrome User Experience Report (CrUX). This is what Google uses for Search. It needs enough traffic to exist and reflects a rolling 28-day window.
• Lab data comes from a simulated test on one device and connection. It is useful for debugging but can differ a lot from real visits.

If your site is new or low-traffic, Search Console and PageSpeed Insights may show “not enough data.” In that case, rely on lab tests and fix the obvious problems; the field data will arrive as traffic grows.

Where to start: a 6-step plan

1. Open the Core Web Vitals report in Google Search Console. Start with mobile, since that is where most sites struggle.
2. Identify the failing metric and URL group. Search Console groups similar pages, so one fix to a template often clears many URLs.
3. Test a sample URL in PageSpeed Insights and read the diagnostics for the failing metric.
4. Fix the biggest causes first: images and hosting for LCP, third-party scripts for INP, missing image dimensions and injected banners for CLS.
5. Validate the fix in Search Console. The validation tracks real-user data over about 28 days, so expect a wait.
6. Add performance checks to your routine. Re-test after installing a new plugin, app, theme or tracking tag. Our technical SEO checklist covers the other crawl and indexing checks to run alongside it.

If you run an online store, many of these steps apply directly to speeding up a Shopify store. If you are choosing a website platform, compare how each one handles hosting, images and scripts; our WordPress vs Wix vs Squarespace comparison is a good starting point.

Common myths about Core Web Vitals

• “A 100 score in PageSpeed Insights is required.” The headline score is a lab score. Google’s Search use of Core Web Vitals relies on field data and the 3 thresholds, not the 0-100 Lighthouse score.
• “Good vitals guarantee top rankings.” They don’t. Relevance, content quality and links still carry more weight. See our on-page SEO checklist for the content side.
• “Only developers can improve them.” Many fixes, such as compressing images, removing unused plugins and cutting old tracking tags, are things a site owner can do.
• “FID still matters.” FID was retired as a Core Web Vital in March 2024. If a report or audit still focuses on it, it is out of date.

The bottom line

Core Web Vitals turn “is the site fast?” into 3 measurable questions: does the main content load within 2.5 seconds, does the page respond within 200 milliseconds, and does the layout stay put? Hit those targets for 75% of real visits on your key templates, especially on mobile, and you remove a ranking handicap while making the site nicer to use. Then return to what moves rankings most: useful, relevant content.

Sources

• Google Search Central: Understanding Core Web Vitals and Google search results — role in ranking and target values
• Google Search Central: Understanding page experience in Google Search results — relevance versus page experience, page-level evaluation
• web.dev: Web Vitals — 75th percentile rule, metric lifecycle and measurement tools
• web.dev: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift — thresholds and what each metric counts
• web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12 — INP replacing FID