Core Web Vitals are three metrics Google uses to measure real-world user experience on a web page: how fast the main content loads, how quickly the page responds when someone interacts with it, and how stable the layout stays while it loads.
They matter because they turn "this site feels slow" into numbers you can track and fix. They also feed into Google's page experience signals, though, as we will cover, they are far from the whole ranking story.
What are Core Web Vitals?
Core Web Vitals are a subset of Google's broader Web Vitals initiative. As of 2026, the set includes three stable metrics, each with a "good" threshold published on web.dev:
- Largest Contentful Paint (LCP) measures loading. It is the time until the largest visible image or text block renders. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP) measures responsiveness. It looks at how long the page takes to visually respond after clicks, taps and key presses. Good is 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability. It scores how much content jumps around unexpectedly. Good is 0.1 or less.
The set changes slowly on purpose. INP became a stable Core Web Vital in 2024, replacing First Input Delay (FID), after spending time as a pending metric. Google says stable metrics change no more than once a year, so it is worth checking web.dev occasionally for updates.
Why Core Web Vitals matter
The first reason is people. A page that loads slowly, ignores taps or shifts a button right as you click it frustrates visitors. That costs conversions no matter where the traffic came from.
The second reason is search. Google's Core Web Vitals documentation says these metrics align with what its core ranking systems seek to reward, and it highly recommends achieving good scores. But Google is just as clear about the limits. Its page experience guide says there is no single page experience signal, that relevance comes first, and that good scores do not guarantee top rankings.
In practice, Core Web Vitals work more like a tiebreaker than a trump card. When many pages on the SERP are equally helpful and relevant, a better experience can help. A fast page with thin content will not outrank a genuinely better answer.
For AI search, the connection is indirect. Google says AI Overviews and AI Mode have no additional technical requirements beyond normal Search eligibility. Speed still helps crawlers, though. Google's crawling myths and facts page confirms that faster loading and rendering let it crawl more pages, which matters for crawl budget and supports indexing.
How Core Web Vitals work
Field data vs. lab data
Core Web Vitals are meant to be measured with field data, meaning data from real visitors on real devices and networks. Google's main public source is the Chrome User Experience Report (CrUX), which powers the field section of PageSpeed Insights and the Core Web Vitals report in Search Console.
Lab data comes from a simulated test, such as Lighthouse or Chrome DevTools. Lab tools are great for debugging, but they are not what Google's field reports use. Lighthouse cannot measure INP at all because no real user is clicking, so it uses Total Blocking Time as a proxy.
The 75th percentile rule
A page "passes" when it meets the good threshold for all three metrics at the 75th percentile of page loads, measured separately for mobile and desktop. Google's threshold methodology article explains why: at that percentile, most visits hit the target, while a handful of extreme outliers cannot skew the result.
Good, needs improvement and poor
Each metric has three bands, per web.dev:
- LCP: good at 2.5 seconds or less, poor above 4 seconds.
- INP: good at 200 milliseconds or less, poor above 500 milliseconds.
- CLS: good at 0.1 or less, poor above 0.25.
Anything between good and poor is "needs improvement."
Page-level and group-level assessment
Google says its ranking systems generally evaluate content page by page, though some assessments are site-wide. Search Console groups similar URLs together in its report, so one slow template can drag down hundreds of pages at once.
Core Web Vitals in practice
Imagine a generic B2B software company whose blog posts load a large hero image, a cookie banner and a chat widget. Search Console flags the blog template on mobile as "needs improvement" for LCP and "poor" for CLS.
The team runs PageSpeed Insights and finds three issues. The hero image is lazy-loaded, so the browser discovers it late. The cookie banner pushes content down after it appears. The chat widget runs heavy JavaScript the moment the page loads.
The fixes are straightforward. They remove lazy-loading from the hero image and give it a high fetch priority. They reserve space for the banner so it overlays rather than shifts content. They delay the chat widget until after the main content is interactive. Because field data is gathered from real visits over time, the team expects the report to update gradually rather than overnight.
Notice what did not happen: no promise of a ranking jump. The real win is a page that feels better to use, with a possible search benefit on top.
How to improve Core Web Vitals
Improving LCP
Google's LCP optimization guide breaks LCP into four parts: server response time, resource load delay, resource load duration and render delay. Useful steps include:
- Make the LCP image discoverable in the initial HTML, not hidden in CSS or JavaScript.
- Never lazy-load the LCP image. Add fetchpriority="high" to it instead.
- Compress and resize images, and use modern formats like WebP or AVIF.
- Use a CDN and caching to cut server response time.
- Reduce render-blocking CSS and defer non-critical scripts.
Improving INP
- Break up long JavaScript tasks so the main thread can respond to input.
- Audit third-party scripts like chat, analytics and ad tags, and load them later where possible.
- Keep event handlers light and avoid huge DOM updates after each click.
Improving CLS
- Set width and height attributes, or aspect ratios, on images and video.
- Reserve space for ads, embeds and banners before they load.
- Avoid inserting content above existing content unless the user asked for it.
- Use font loading strategies that limit layout shifts when web fonts swap in.
Common mistakes and misconceptions
- Chasing a perfect Lighthouse score. Lab scores are diagnostic. Google's field data is what reflects real users, and the two can differ a lot.
- Thinking Core Web Vitals outrank content. Google says relevance comes first. Speed will not rescue content that does not answer the query.
- Ignoring mobile. Google mostly indexes the mobile version of sites, and mobile devices and networks are usually where scores suffer.
- Expecting instant results. Field data is collected over time, so improvements show up gradually.
- Still optimizing for FID. INP replaced FID in 2024. Older guides may point you at the wrong metric.
- Forgetting third-party scripts. Tags added by marketing tools are a frequent cause of poor INP and CLS.
Core Web Vitals vs. page speed
"Page speed" is a loose phrase that can mean anything from server response time to a single Lighthouse score. Core Web Vitals are specific. They measure three defined parts of experience, using real-user data, at a set percentile. A page can feel fast on your office Wi-Fi and still fail Core Web Vitals for mobile visitors on slower connections.
How Butter approaches Core Web Vitals
At Butter, we look at Core Web Vitals as part of technical health, alongside crawlability and indexing, rather than as a standalone vanity score. We start with field data from Search Console, because that is what reflects your real visitors, then use lab tools to find the cause.
On our GEO+SEO plan, technical SEO fixes and unlimited on-page optimization give us room to address issues like oversized hero images, layout shifts from embeds and heavy scripts on key templates. The Butter Analytics dashboard connects to Google Search Console and Google Analytics, so you can see whether changes hold up over time. On the GEO plan, we include performance issues in our monthly on-page recommendations.
We are honest about the payoff. Better Core Web Vitals improve the experience for every visitor and can help in search, but we never promise rankings from speed work alone.
Frequently asked questions
Are Core Web Vitals a Google ranking factor?
Google says Core Web Vitals align with what its core ranking systems seek to reward, as part of page experience. It also says there is no single page experience signal and that relevance comes first. Treat them as one helpful input, not a shortcut to the top.
What are the current Core Web Vitals thresholds?
As of 2026, good scores are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. They are measured at the 75th percentile of page loads, separately for mobile and desktop.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay as a stable Core Web Vital in 2024. INP looks at responsiveness across interactions on the page, not just the first one.
Where can I check my Core Web Vitals?
Search Console's Core Web Vitals report and PageSpeed Insights both show field data from real Chrome users. Lighthouse and Chrome DevTools are useful for debugging in a lab setting.