Core Web Vitals are Google’s specific set of real-world user experience metrics that measure loading performance, interactivity, and visual stability. They became a confirmed ranking signal with the Page Experience Update in June 2021. Unlike lab-based performance scores, Core Web Vitals are primarily measured using field data — real usage collected from Chrome users on actual devices and network conditions, aggregated in the Chrome User Experience Report (CrUX).
In March 2024, Google replaced FID (First Input Delay) with INP (Interaction to Next Paint) as the responsiveness metric. FID measured only a page’s response to its very first interaction; INP measures responsiveness throughout the entire page lifecycle, making it a more comprehensive and meaningful signal for interactive pages.
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed of the main visual element | ≤2.5s | 2.5–4s | >4s |
| INP (Interaction to Next Paint) | Response time to user interactions | ≤200ms | 200–500ms | >500ms |
| CLS (Cumulative Layout Shift) | Visual stability — unexpected layout shifts | ≤0.1 | 0.1–0.25 | >0.25 |
A page “passes” Core Web Vitals when all three metrics reach the “Good” threshold for at least 75% of real-user page loads. The 75th percentile standard means you must perform well for the majority of users, not just average users — slow tail-end experiences count against you.
LCP measures when the largest visible content element finishes rendering in the viewport. The element is typically a hero image, a large text block (such as an H1 heading with no image above it), or a video poster frame. A good LCP tells Google that your page’s main content is available to users quickly.
srcset to serve appropriately sized images to different screen sizesrel="preload" for the LCP image so the browser fetches it as early as possibleINP measures the time from a user interaction — a click, a tap, or a keypress — until the next frame is painted showing the visual result of that interaction. This replaced FID in March 2024. Where FID only captured the latency of the first interaction after page load, INP captures the worst interaction latency across the entire page session, making it sensitive to sluggishness anywhere in the user journey.
setTimeout or the Scheduler API to yield to the main thread between tasksCLS measures how much visible content shifts unexpectedly during page load. Each unexpected shift is assigned a score based on the fraction of viewport affected and the distance the element moved. These scores are summed to produce the CLS for the page session. A CLS above 0.25 creates a jarring experience — buttons move as users try to click them, text jumps as images load above it.
width and height attributes — the browser doesn’t know how much space to reserve, so it reflows the layout when the image loadswidth and height on every <img> tag — modern browsers use these to calculate aspect ratio and reserve space before the image loadsmin-height container so the layout doesn’t shift when the ad fills infont-display: swap and preload critical fonts to minimise the fallback-to-web-font transitionSeveral free tools measure Core Web Vitals, each with slightly different data sources:
Lab data vs field data: Lighthouse and DevTools use simulated conditions (lab data). Google Search Console and PageSpeed Insights field data reflect real users. Your lab score can look good while your field CWV still fails — always check field data before declaring a page fixed.
Core Web Vitals function as a tiebreaker signal in Google’s ranking algorithm. When two pages are equally relevant and authoritative for a query, Google uses page experience signals — including CWV — to determine which ranks higher. A page with good content and good CWV beats an equally good page with poor CWV.
They do not override content relevance. A genuinely useful, authoritative page can still rank above a fast but thin page. In competitive niches where the top-ranking pages all have strong content, CWV can become a meaningful differentiator — particularly for mobile rankings, where slow pages create a noticeably worse user experience.
Google Ads, analytics platforms, live chat widgets, social media embeds, and A/B testing tools are among the most frequent causes of poor LCP and INP. They execute on your main thread, add to your page weight, and often cannot be removed without losing business functionality.
The most effective technique for managing them is facade loading: display a static placeholder image or button instead of loading the actual third-party script until the user interacts with it. A YouTube video embedded via a facade shows only the thumbnail and a play button; the actual YouTube iframe — with all its associated JavaScript — loads only when the user clicks play. This pattern can improve LCP by multiple seconds on pages with heavy embeds.
Core Web Vitals · Page Experience · SEO fundamentals · Instant feedback
Test Your SEO KnowledgeThey are a ranking factor, but a secondary one compared to content relevance and links. Think of them as a tiebreaker between pages of similar quality. Strong content with good CWV beats strong content with poor CWV, but excellent CWV cannot rescue genuinely thin or irrelevant content.
FCP (First Contentful Paint) measures when any content first appears on screen — the very first pixel of text or image. LCP measures when the largest or most visually significant content element finishes rendering. FCP is faster and useful as an early loading signal, but LCP is the more meaningful metric for how quickly the page actually feels loaded to a user.
INP — Interaction to Next Paint — replaced FID (First Input Delay) in March 2024. FID only measured the delay before the browser could begin processing the very first user interaction. INP measures responsiveness throughout the entire page lifecycle, capturing any interaction that causes a slow response — making it a significantly more comprehensive measure of real-world interactivity.
Yes — Google measures Core Web Vitals separately for mobile and desktop using real user data from the Chrome User Experience Report. The thresholds (Good / Needs Improvement / Poor) are the same for both device categories, but mobile pages frequently score worse due to less powerful devices, slower network connections, and the same JavaScript executing on hardware with much less processing capacity than a desktop.