Core Web Vitals are Google's way of measuring whether a page actually feels good to use. Instead of abstract “speed scores”, they focus on three things real visitors notice: how quickly the main content appears, how fast the page responds when you tap or click, and whether the layout jumps around while loading.
They matter for two reasons. First, they reflect user experience, which affects bounce rates and conversions. Second, Google uses page experience signals, including Core Web Vitals, as part of how it evaluates pages. They will not rescue weak content, but on competitive queries a slow, jumpy page is a handicap you do not need.
This guide explains each metric (LCP, INP and CLS) in plain English, the official thresholds, how to measure them correctly, a step-by-step process to improve them, and the mistakes teams commonly make in 2026.
Key Takeaways
- The three Core Web Vitals are Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability).
- Good thresholds are LCP ≤ 2.5s, INP ≤ 200ms and CLS ≤ 0.1, assessed at the 75th percentile of page loads.
- INP replaced First Input Delay as a Core Web Vital on March 12, 2024.
- Field data from real users (CrUX) is what counts; lab tools are for diagnosing problems.
- Fix failing page templates rather than individual URLs for the biggest gains.
What are Core Web Vitals?
Core Web Vitals are a subset of Google's Web Vitals initiative. Each one measures a distinct part of the user experience, and each has a threshold that defines “good”.
“a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.”
— web.dev, Web Vitals
In practice, this means at least 75% of visits to your page need to hit the “good” threshold for the page to pass that metric. A page passes the Core Web Vitals assessment when all three metrics are good.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance | ≤ 2.5 s | 2.5 s – 4.0 s | > 4.0 s |
| Interaction to Next Paint (INP) | Responsiveness | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | Visual stability | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible image or text block in the viewport to render, counted from when the page starts loading. Elements that can count include <img> elements, images inside SVG, video poster images, elements with a CSS background image, and block-level text elements. On most pages, the LCP element is a hero image or the main headline.
web.dev breaks LCP into four sub-parts, which makes it much easier to diagnose:
- Time to First Byte (TTFB): how long until the browser receives the first byte of HTML.
- Resource load delay: the gap between TTFB and the LCP resource starting to download.
- Resource load duration: how long the LCP resource (usually an image) takes to download.
- Element render delay: the time between the resource finishing and the element appearing on screen.
Common fixes include making the LCP image discoverable in the HTML, adding fetchpriority="high" to it, never lazy-loading it, compressing and resizing images, and reducing server response time.
Interaction to Next Paint (INP)
INP assesses how quickly a page responds to user interactions such as clicks, taps and key presses throughout the visit. It reports a value close to the slowest interaction, so one sluggish menu or filter can drag the score down. Each interaction has three phases:
- Input delay: waiting for the main thread to be free to handle the event.
- Processing duration: running the event handlers.
- Presentation delay: rendering and painting the next frame.
Poor INP is almost always caused by too much JavaScript on the main thread: heavy frameworks, third-party tags, chat widgets and analytics scripts. Breaking up long tasks, deferring non-essential scripts and reducing DOM size are the main levers. Our guide on JavaScript SEO covers related rendering issues.
Cumulative Layout Shift (CLS)
CLS measures unexpected movement of visible content. If you have ever tapped a button just as an ad loaded and pushed it down, you have experienced a layout shift. CLS takes the largest burst of shifts (a “session window” of shifts less than one second apart, lasting up to five seconds) and reports its score.
Typical causes are images and videos without dimensions, ads and embeds that resize, content injected above existing content, and web fonts that render at a different size from the fallback font. Setting width and height on media and reserving space for ads fixes most issues.
How to measure Core Web Vitals
| Tool | Data type | Best for |
|---|---|---|
| Search Console Core Web Vitals report | Field (real users, grouped URLs) | Seeing which templates fail across your site |
| PageSpeed Insights | Field (CrUX, 28 days) and lab (Lighthouse) | Checking a single URL and getting diagnostics |
| Chrome DevTools Performance panel | Lab and local field | Debugging specific interactions and long tasks |
| web-vitals JavaScript library | Field (your own users) | Sending real-user metrics to analytics |
| CrUX dashboard / API | Field | Tracking trends and comparing competitors |
Lab tools test one simulated load on a fixed device and network, which is useful for debugging but does not reflect your real audience. Prioritise field data when deciding what to fix. If you are still learning Search Console, see everything about Google Search Console.
How to improve Core Web Vitals: step by step
- Find failing groups. Open the Core Web Vitals report in Search Console for mobile and desktop and note which metric fails and on which URL groups.
- Pick a representative URL. Test it in PageSpeed Insights to see field data and lab diagnostics.
- Identify the cause. For LCP, find the LCP element and which sub-part is slowest. For INP, record interactions in DevTools. For CLS, highlight layout shift regions.
- Fix at template level. Changes to a theme, component or shared script fix thousands of pages at once.
- Deploy and validate. Use “Validate fix” in Search Console and watch field data over the following 28 days.
- Monitor continuously. New plugins, tags and campaigns can quietly reintroduce problems.
For a full list of practical speed improvements, read how to improve page speed, and for a broader view of where vitals fit, see our technical SEO guide.
Do Core Web Vitals affect rankings?
Google's documentation states that it highly recommends site owners achieve good Core Web Vitals for success with Search, and that this, along with other page experience aspects, aligns with what its core ranking systems seek to reward. It does not say good scores guarantee rankings. Treat vitals as a tie-breaker and a conversion booster, not a substitute for relevant, helpful content. Mobile performance is especially important; see our guide to mobile SEO.
Common mistakes
- Optimising for the Lighthouse score. A lab score of 100 does not mean real users pass.
- Lazy-loading the hero image. This delays LCP on almost every page it is applied to.
- Still talking about FID. FID was retired as a Core Web Vital in 2024; INP is the metric that matters.
- Ignoring third-party scripts. Tag managers, chat widgets and A/B testing tools are frequent INP culprits.
- Fixing one URL at a time. Fix the shared template instead.
- Expecting instant results. Field data reflects a rolling 28-day window.
Related Guides
- How to Improve Page Speed: 15 Practical Fixes
- XML Sitemaps: How to Create and Submit One
- 301 vs 302 Redirects: Which One Should You Use?
Frequently Asked Questions
What are good Core Web Vitals scores?
According to web.dev, a good score is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop separately.
Are Core Web Vitals a ranking factor?
Google says good Core Web Vitals align with what its core ranking systems seek to reward, and it recommends achieving them for success with Search. They are one of many signals, though, and relevance and content quality matter more.
What happened to First Input Delay (FID)?
Interaction to Next Paint (INP) replaced FID as a Core Web Vital on March 12, 2024. INP measures responsiveness across all interactions on a page, not just the delay before the first one.
Why do PageSpeed Insights and Search Console show different numbers?
Search Console groups similar URLs and reports field data from real Chrome users. PageSpeed Insights shows field data for a single URL or origin plus a lab test from one simulated load. Lab and field results often differ.
How long does it take for Core Web Vitals improvements to show?
Field data in CrUX covers a rolling 28-day period, so improvements appear gradually over about four weeks after a fix goes live.
Conclusion
Core Web Vitals turn “site speed” into three clear, measurable goals: load the main content within 2.5 seconds, respond to interactions within 200 milliseconds, and keep the layout stable with a CLS of 0.1 or less. Measure with field data, fix templates, and monitor continuously. If you want specialists to do the heavy lifting, our page speed optimization service and web development team can help. Get a free quote.
References
- Web Vitals – web.dev
- Largest Contentful Paint (LCP) – web.dev
- Interaction to Next Paint (INP) – web.dev
- Cumulative Layout Shift (CLS) – web.dev
- Interaction to Next Paint becomes a Core Web Vital on March 12 – web.dev
- Understanding Core Web Vitals and Google search results – Google Search Central
- Core Web Vitals: What They Are & How to Improve Them – Semrush Blog
