Core Web Vitals in 2026: the current metric set
The current Core Web Vitals are LCP, INP and CLS. LCP measures loading performance, INP measures interaction responsiveness and CLS measures visual stability. Google presents them as three user-centric aspects of real-world page experience. [1][3]
FID is no longer part of Core Web Vitals. INP replaced FID in March 2024 and FID was later removed from CrUX tooling. In 2026 teams should monitor LCP, INP and CLS. [7][14]
LCP, INP and CLS thresholds and the 75th percentile
| Metric | Good | Needs improvement | Poor | What it measures |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Main-content loading speed |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Interaction responsiveness |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Visual stability |
Good values are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Needs Improvement covers 2.5 to 4.0 seconds, 200 to 500 milliseconds and 0.1 to 0.25 respectively. Values above 4.0 seconds, 500 milliseconds and 0.25 are poor. [3][4]
Assessment does not use an average. Google uses the 75th percentile, meaning at least 75% of experiences should meet the threshold or perform better. Mobile and desktop are segmented separately. [3][4]
A page passes Core Web Vitals only when all three metrics are good at the 75th percentile. One failing metric means the overall assessment does not pass. [3]
Core Web Vitals and SEO: a real signal, not a standalone ranking system
Google confirms that Core Web Vitals are used by ranking systems as part of page experience. At the same time, good Core Web Vitals do not guarantee top rankings because Search uses many other signals, especially relevance and content quality. [1][2]
Performance optimization therefore has two goals: improving real user experience and removing technical weaknesses that can affect search performance. LCP, INP and CLS should not be treated as a separate point system detached from content quality.
LCP: what it actually measures
Largest Contentful Paint measures the time from navigation start until the largest qualifying image, text block or other content element is rendered in the viewport. Field LCP can include redirects, connection setup and TTFB, which is one reason field and lab results can differ. [5]
A common mistake is treating LCP as just the download time of the biggest image. The LCP element can be an image or text, and the delay can be introduced long before the resource download itself. [5][6]
LCP in practice: split it into four subparts
web.dev breaks LCP into four subparts: TTFB, resource load delay, resource load duration and element render delay. Together they make up the full LCP time. [6]
If the LCP resource is discovered late, merely compressing it may not improve the final metric. The resource should be discoverable from the initial HTML where possible, and an LCP image should not use lazy loading. Priority hints or preload can help when discovery is delayed. [6]
A practical diagnosis order is: check TTFB, determine when the browser discovers the LCP resource, measure transfer duration, then identify what delays rendering after the resource is available. [6]
- Reduce TTFB with caching, CDN use, fewer redirects and a faster backend.
- Expose the LCP resource in initial HTML where possible.
- Do not use `loading="lazy"` on the LCP image.
- Use appropriate `fetchpriority` or preload when discovery is too late.
- Optimize image size and format only after confirming transfer time is a real bottleneck.
- Remove JavaScript or CSS that unnecessarily delays the final render.
INP: responsiveness across the visit, not just the first click
Interaction to Next Paint observes latency for click, tap and keyboard interactions across the page visit. For most pages, the slowest interaction becomes the reported INP. On pages with many interactions, one worst interaction is ignored for every 50 interactions to reduce random outlier influence. [7]
INP differs from FID. FID measured only the input delay of the first interaction, while INP includes input delay, event processing and the delay until the browser can paint the next frame. [7][8]
A visit may have no INP if the user never clicks, taps or presses a key. Scrolling and hovering are not INP interactions. [7]
INP in practice: three places where latency appears
Total interaction latency consists of input delay, processing duration and presentation delay. A poor INP can therefore come from a busy main thread before the handler, slow event code, or expensive layout and rendering before the next frame. [8]
Useful fixes include shortening long tasks, yielding or splitting work, reducing heavy JavaScript, lowering layout cost, moving suitable computation to Web Workers and providing visual feedback quickly. [8]
For high INP, start with field or RUM data that identifies the slow interaction and then reproduce it in DevTools. A Lighthouse score by itself does not represent full real-user INP. [8][11][12]
CLS: visual stability across the page lifetime
Cumulative Layout Shift measures unexpected movement of visible elements. The score uses the largest session window of shifts, where consecutive shifts are less than one second apart and the whole window lasts no more than five seconds. [9]
CLS is unitless. It combines the impact and movement distance of unexpected layout changes rather than measuring time. Some shifts closely tied to user input can be excluded. [9]
Real CLS problems often happen after load, for example when ads, banners, widgets or fonts change layout. A single cold-load lab test may therefore miss the full issue. [10][11]
CLS in practice: common causes and fixes
web.dev lists images without dimensions, ads, embeds and iframes without reserved space, dynamically injected content and web fonts among common CLS causes. [10]
The core rule is to reserve space before content arrives. Images should have `width` and `height` or stable `aspect-ratio`, ad and embed slots need predictable dimensions, and new content should not be inserted above content a user is already reading. [10]
For fonts, reduce metric differences between fallback and final fonts and test the real layout impact. Changing `font-display` alone does not automatically solve every CLS issue. [10]
Field data versus lab data: do not mix two different questions
Core Web Vitals are primarily field metrics. CrUX and your own RUM show what real users experience across devices and networks. Lighthouse is a lab tool for reproducing and diagnosing issues under controlled conditions. [11][12]
Lighthouse does not report full real-world INP because it does not observe natural user interactions. It uses metrics such as Total Blocking Time as a lab proxy. Lab CLS can also be lower if shifts occur only after later interactions. [11][12]
Use field data to decide whether a real problem exists, and lab tools to understand and fix the cause.
PageSpeed Insights, Search Console, DevTools and RUM: what each tool is for
| Tool | Data type | Best use |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Quick URL and origin assessment |
| Search Console | CrUX, URL groups | Finding page groups with SEO performance issues |
| Chrome DevTools | Lab + CrUX context | Step-by-step LCP, INP and CLS diagnosis |
| Lighthouse | Lab | Automated audits and CI regression checks |
| RUM / web-vitals | Your own user data | Most precise monitoring and post-release diagnosis |
PageSpeed Insights combines CrUX field data with Lighthouse diagnostics. Search Console groups similar URLs to identify page types failing Core Web Vitals. Chrome DevTools provides live metrics and detailed performance traces. [12][13]
CrUX API and PageSpeed Insights effectively use a rolling window of roughly 28 days for field data. A deployment made today may therefore take time to affect the public p75 score. Your own RUM can show the impact much sooner and with more context. [12][13]
A strong product workflow uses RUM for monitoring, Search Console for SEO-oriented grouping, PageSpeed Insights for quick public checks and DevTools for root-cause analysis.
CrUX in 2026: what the latest available data shows
| Metric | Origins with a good score, July 2026 |
|---|---|
| LCP | 68.3% |
| INP | 85.7% |
| CLS | 81.6% |
| All Core Web Vitals | 55.7% |
The latest monthly CrUX dataset published before September 4, 2026 covers July 2026 and was released on August 11. It contains 18,059,068 origins. 68.3% of origins had good LCP, 81.6% good CLS, 85.7% good INP and 55.7% passed all Core Web Vitals. [14]
These are aggregate figures for the web represented in CrUX, not targets for an individual site. CrUX only includes pages and origins that satisfy eligibility criteria such as public discoverability and sufficient popularity. [13][14]
Missing CrUX data for a new or low-traffic URL does not mean that page is fast or slow. It means the public dataset does not have enough eligible data to report.
SPAs and soft navigations: an important 2026 change
Core Web Vitals historically centered on full document navigations, which made client-side SPA transitions harder to measure. In 2026 Chrome 151 introduced new APIs for measuring Core Web Vitals on soft navigations, and the documentation was updated on September 2, 2026. [15]
Chrome DevTools 152, released August 25, 2026, shows Core Web Vitals for soft navigations in Live Metrics by default, powered by `web-vitals` 6.0.0. [16]
This matters for React, Angular, Vue and other SPAs because LCP, INP or CLS problems can occur after client-side navigation even when the initial full load looks good. Do not assume that every public CrUX report already treats soft navigations the same way.
Production monitoring: collect the metric together with context
A public p75 tells you that a problem exists but often not exactly where it comes from. Your own RUM can attach the LCP element and subparts, the INP interaction and event type, route, device class and application version. web.dev recommends custom RUM as a supplement to CrUX for diagnosis. [3][8][12]
Tag releases with application versions and compare metric distributions before and after changes. An average can hide regressions on slower devices, so watch percentiles and traffic segments.
CI should protect against obvious lab regressions, but it cannot replace production monitoring. Final Core Web Vitals assessment is about real user experience. [11][12]
A practical Core Web Vitals improvement plan
First identify which metric fails p75 and on which page types. Then use RUM or CrUX to narrow the issue, reproduce it in DevTools, make the smallest change that addresses the root cause and monitor the result after deployment. [12]
Do not optimize everything at once. For LCP find the dominant subpart, for INP identify the actual slow interaction, and for CLS capture the specific shifts and elements causing them.
After the fix, check both lab and field data. Public CrUX data needs time to reflect a new release, which is why custom RUM is especially useful for quick validation.
- Identify the problem in field data, not just Lighthouse.
- Separate mobile and desktop and group similar page templates.
- For LCP inspect TTFB, resource discovery, transfer and render delay.
- For INP inspect the actual interaction and its input, processing and presentation delay.
- For CLS record shifts across the full session, not just initial load.
- Ship one measurable fix and compare before and after.
- Keep RUM monitoring and regression alerts active after release.
