Core Web Vitals: what they are and how to pass

Core Web Vitals are the three metrics Google uses to measure real-user page experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). To pass, you need LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of your real visitors. Here is the honest part most guides skip: Core Web Vitals are a genuine but weak ranking signal. Google has said as much. They act as a tiebreaker between comparable pages and as a user-experience safeguard, not as a lever that lifts thin content above better content. Fix them because slow, jumpy pages lose customers, and take the small ranking benefit as a bonus.

This is a spoke in our technical SEO pillar. If Core Web Vitals is on your list, page speed and crawlability usually are too.

What are Core Web Vitals

Google introduced Core Web Vitals as a small set of user-centric metrics that quantify how a page actually feels to load and use. They sit inside the broader page experience signals alongside HTTPS and mobile-friendliness. Per Google Search Central, page experience is one of many factors the ranking systems weigh, and great page experience does not override having genuinely helpful content.

The three metrics each cover a different moment in the user journey:

• Largest Contentful Paint (LCP) measures loading. It marks when the biggest visible element (usually a hero image, video poster, or large text block) finishes rendering.
• Interaction to Next Paint (INP) measures responsiveness. It reflects how quickly the page reacts to taps, clicks, and key presses across the whole visit, not just the first one.
• Cumulative Layout Shift (CLS) measures visual stability. It scores how much content jumps around while the page loads.

Core Web Vitals thresholds

Here are the current pass thresholds. A page is judged at the 75th percentile of page loads, meaning 75 percent of your real visits must hit the target.

These figures come from web.dev's Web Vitals reference. You need all three in the good band to pass. One poor metric fails the whole set.

INP replaced FID in March 2024

The change most old guides miss: on 12 March 2024, Interaction to Next Paint officially replaced First Input Delay (FID) as the responsiveness Core Web Vital, confirmed in web.dev's launch announcement. FID only measured the delay before the browser started processing your very first interaction. It was easy to pass and rarely reflected reality, because a page could score a perfect FID and still freeze on every subsequent tap.

INP is stricter and more honest. As web.dev explains, it observes the latency of all interactions during the visit and reports a value near the worst one. Sites that coasted on good FID scores often fail INP, because the real culprit (long JavaScript tasks blocking the main thread) was always there. Google removed FID from Search Console the day INP took over, so if your last audit was before 2024 and said you passed, re-check it against INP.

Field data vs lab data: where teams waste weeks

This is the single most expensive misunderstanding in Core Web Vitals work, so read it twice.

There are two sources of Core Web Vitals data, and they disagree constantly:

• Lab data comes from a controlled test: Lighthouse, PageSpeed Insights' lab section, or a local DevTools run. One load, one simulated device, one simulated network. Deterministic and repeatable, which makes it good for debugging.
• Field data comes from the Chrome User Experience Report (CrUX): anonymised measurements from real Chrome users who visited your page. This is what Google uses for the ranking signal, per the CrUX documentation.

The trap: Lighthouse (lab) shows a green 98 and says you pass, while Search Console and CrUX (field) say you fail. Teams then spend weeks re-running Lighthouse, tweaking things it already scores well, and getting nowhere, because they are optimising the wrong data source.

The gap exists because CrUX reflects your actual visitor population. Plenty of those users are on mid-range Android phones over congested 4G, with cold caches and a dozen background tabs. Your MacBook on office fibre is not that population. Lab tests on a fast machine hide the exact slowness real users feel, especially for INP, which depends heavily on device CPU.

Rule of thumb: use field data (CrUX, Search Console's Core Web Vitals report) to decide whether you pass, and lab data (Lighthouse) to diagnose why. Never ship based on the lab number alone. Diagnosing field-vs-lab disagreements is core to any technical SEO audit.

How to pass Core Web Vitals

Work metric by metric. Here are the fixes that actually move the numbers.

Fix LCP (target 2.5s)

LCP is usually an image or slow-server problem. Per web.dev's LCP guide, the LCP element and its resource load path are what matter:

• Serve the hero image in a modern format (WebP or AVIF), correctly sized, and mark it high priority instead of lazy-loading it.
• Improve server response time (TTFB) with caching and a CDN that has edge locations near your audience.
• Preload the LCP image and critical fonts so the browser fetches them early.
• Remove render-blocking CSS and JavaScript from the critical path.

Deeper tactics live in our guide on how to improve page speed.

Fix INP (target 200ms)

INP is a JavaScript problem almost every time:

• Break up long tasks. Any script that occupies the main thread for more than 50ms will make interactions feel laggy.
• Defer or remove non-critical third-party scripts (chat widgets, heavy analytics, ad tags).
• Avoid expensive work in event handlers; yield back to the browser so it can paint.
• Ship less JavaScript overall. Server-side rendering and code-splitting help.

Fix CLS (target 0.1)

CLS is usually cheap to fix once you find the cause:

• Set explicit width and height (or aspect-ratio) on every image and video so the browser reserves space.
• Reserve space for ads, embeds, and banners instead of letting them push content down.
• Preload fonts and use font-display so text does not reflow when the web font arrives.
• Never insert content above existing content after load.

Do Core Web Vitals affect SEO rankings

Yes, but modestly. They are a real ranking signal and part of Google's page experience systems, confirmed in the page experience documentation. What they are not is a shortcut. Passing them will not push a weaker page above a stronger one on relevance and content. Think of them as a tiebreaker: when two pages are otherwise comparable, the faster, more stable one has an edge. The bigger, more reliable payoff is conversion. Faster pages keep more visitors, so the business case stands even if the ranking lift is small.

Core Web Vitals sit inside a wider technical foundation. Make sure Google can also reach and understand your pages: get crawling and indexing right, keep a clean XML sitemap, and check that JavaScript SEO is not hiding content behind client-side rendering, which also tanks LCP and INP.

Optimise for the hardest case and pass everywhere

Here is a practical strategy that turns a demanding audience into an advantage. Because CrUX measures your real users, the toughest population sets your bar. If a large share of your traffic is on budget Android devices over uneven mobile networks, as is common across India and much of the world, optimise for exactly those conditions. Test on a throttled connection and a mid-range phone, not a flagship on WiFi.

The upside compounds: a page tuned to stay fast and stable on a ₹12,000 phone over 4G will comfortably pass CrUX for users on faster hardware everywhere. You do not need to optimise separately for each market. Nail the hardest case and the rest come free. Tune for the flagship instead and you pass in the lab while failing the field.

Measure it correctly

• Use Search Console's Core Web Vitals report for the field verdict Google actually uses; it groups your URLs into passing and failing buckets from CrUX.
• Use PageSpeed Insights to see field and lab data side by side for a single URL.
• Use Lighthouse in Chrome DevTools to debug the why, with CPU and network throttling turned on.
• Track changes over time, since CrUX is a rolling 28-day dataset and improvements take weeks to show up in the field.

A technical site audit will surface your Core Web Vitals issues alongside crawl, indexing, and on-page problems in one report, and you can watch the ranking impact of your fixes in rank tracking. Just remember the order: diagnose in the lab, judge in the field, and fix the hardest device first.