Core Web Vitals & Modern Metrics
The Core Web Vitals Trio: LCP, INP, CLS
Core Web Vitals are Google’s standardized field metrics for measuring user experience, and they directly influence search rankings as part of the Page Experience signals. As of 2026, the three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). The thresholds, evaluated at the 75th percentile of real user data, are: LCP < 2.5s (loading), INP < 200ms (responsiveness), and CLS < 0.1 (visual stability). According to the 2025 Web Almanac, only about 48% of mobile pages pass all three — meaning more than half the web is still failing on mobile. LCP remains the hardest to pass, with only 62% of mobile pages achieving a “good” score. These metrics are supplemented by diagnostic metrics like Time to First Byte (TTFB < 800ms) and First Contentful Paint (FCP < 1.8s), which help identify the root causes of poor LCP.
As Addy Osmani’s history of Core Web Vitals documents, the collective effort to optimize Chrome and websites across the ecosystem saved users an estimated 30,000 years of waiting time in 2024 alone. The business impact is well-documented: Vodafone saw an 8% increase in sales from a 31% LCP improvement, Yahoo! JAPAN achieved 15% more page views per session after fixing CLS issues, and Agrofy saw a 76% drop in load abandonment from a 70% LCP boost.
Resources:
- Core Web Vitals — web.dev
- How the Core Web Vitals Metrics Thresholds Were Defined — Barry Pollard, web.dev
- The History of Core Web Vitals — Addy Osmani
- What Are the Core Web Vitals? LCP, INP & CLS Explained — CoreWebVitals.io
- Core Web Vitals Optimization Guide 2025 — DigitalApplied
Interaction to Next Paint (INP): The New Responsiveness Metric
INP officially replaced First Input Delay (FID) as the responsiveness Core Web Vital on March 12, 2024. The change addressed two fundamental limitations of FID: it only measured the first interaction on a page, and it only captured the input delay phase (the time waiting before the event handler ran). INP measures all interactions throughout the user’s entire session and captures the full interaction lifecycle — input delay, processing time, and presentation delay — reporting the worst interaction (minus outliers). A good INP is 200ms or less; above 500ms is “poor.”
The transition caused roughly a 5-percentage-point drop in mobile Core Web Vitals pass rates according to the HTTP Archive 2025 Web Almanac, because many sites that appeared responsive under FID had slow later interactions that INP now surfaces. INP only tracks discrete user interactions — clicks, taps, and key presses — not scrolling, which is handled by the browser’s compositor thread. However, if you use JavaScript-based scrolling libraries (custom smooth scroll handlers), those callbacks do count toward INP. Using native CSS scroll-behavior avoids this entirely.
To measure INP, use field data first: PageSpeed Insights (backed by CrUX), your RUM provider, or Google’s web-vitals JavaScript library. SpeedCurve’s analysis confirms a negative correlation between INP and conversion rate — higher INP means lower conversions. To optimize INP, focus on breaking up long main-thread tasks, deferring non-critical JavaScript, using requestIdleCallback and the newer scheduler.yield() API, and reducing the impact of third-party scripts.
Resources:
- Interaction to Next Paint (INP) — web.dev
- INP Becomes a Core Web Vital on March 12 — web.dev Blog
- Optimize INP — web.dev
- INP: What It Is, How to Measure and Improve It — CoreWebVitals.io
- Farewell FID… and Hello Interaction to Next Paint — SpeedCurve
- INP (Glossary) — MDN
Long Animation Frames (LoAF) API
The Long Animation Frames API (LoAF), shipped in Chrome 123 in early 2024, is a successor to the Long Tasks API that provides dramatically better attribution data for diagnosing responsiveness issues. Where the Long Tasks API could only tell you that a long task happened, LoAF tells you exactly what caused it — down to the script URL, function name, and character position in the source. A long animation frame is any rendering update delayed beyond 50ms.
LoAF improves on Long Tasks in several critical ways. First, it measures at the frame level rather than the task level, capturing all the work the browser does to produce a visual update — including requestAnimationFrame callbacks, style and layout calculations, ResizeObserver and IntersectionObserver callbacks. Second, its scripts array provides PerformanceScriptTiming entries for every script that ran during the frame, with invoker details that identify the exact entry point. Third, it exposes blockingDuration (how long the main thread was truly blocked), renderStart, and styleAndLayoutStart timestamps for granular analysis.
LoAF is especially powerful for diagnosing INP issues. The web-vitals library (v4+) includes all intersecting LoAFs in the INP attribution interface via the longAnimationFrameEntries property. RUM tools like DebugBear, SpeedCurve, and Sentry have all added LoAF support to surface which scripts contribute most to slow interactions. As of early 2026, LoAF is supported in Chromium browsers; Firefox and Safari support is not yet available, though it has been proposed for the W3C Interop process.
Resources:
- Long Animation Frames API — Chrome for Developers
- Long Animation Frame Timing — MDN
- The Definitive Guide to Long Animation Frames (LoAF) — SpeedCurve
- Measuring Long Animation Frames (LoAFs) in the Browser — DebugBear
- Long Animation Frames API — W3C GitHub Spec
- Long Frames and INP: Understanding Post-Load Performance — DEV Community
Soft Navigation Metrics for SPAs
Single Page Applications have been a blind spot for Core Web Vitals since the program’s inception. Because SPAs update content via JavaScript without triggering a full page reload, the browser sees one continuous session — LCP stops reporting after the first user interaction, CLS accumulates across the entire session rather than per-view, and many in-app transitions are invisible to field metrics. Chrome’s Soft Navigations API, currently in origin trial from Chrome 139 (July 2025), aims to close this gap.
The API uses browser-level heuristics to detect soft navigations automatically — no framework opt-in required. A soft navigation is identified when a user interaction triggers a URL change (via pushState or replaceState), results in DOM modifications, and produces a paint. Each detected navigation is assigned a unique navigationId that is attached to performance entries (LCP, CLS, INP, layout-shift, event-timing), enabling per-view Core Web Vitals measurement. The API also introduces interaction-contentful-paint, a new metric analogous to LCP but scoped to the post-interaction paint following a soft navigation.
This is still experimental — it is not yet reflected in CrUX or Google Search rankings — but the direction is clear. As the 2025 PerfPlanet RUMCG review notes, the broader community is eagerly awaiting standardization, and RUM vendors are preparing to support per-route CWV dashboards. The web-vitals.js library already has an experimental soft-nav branch. If you’re building SPAs with React, Vue, Angular, or Svelte, now is the time to opt into the origin trial and validate that the heuristics correctly detect your app’s navigations.
Resources:
- Experimenting with Measuring Soft Navigations — Chrome for Developers
- New Soft Navigations Origin Trial — Chrome Blog
- A Guide to Soft Navigations and Core Web Vitals Reporting — DebugBear
- Why the Soft Navigations API Enables Better SPA Core Web Vitals Auditing — SALT.agency
- RUMCG — A Year in Review — PerfPlanet 2025
The Shift from Optimization to Prediction: Toward “Instant” Performance
A landmark 2025 PerfPlanet article argues that the web performance community has crossed a threshold: with the maturation of the Speculation Rules API and aggressive prerendering in Chromium browsers, a significant volume of page loads now fall into the sub-300ms category. The author proposes splitting the current “Good” LCP tier (≤2.5s) into three distinct tiers to reflect this new reality: Instant (< 300ms), Fast (300ms–1000ms), and the current “Good” (1000ms–2500ms). Their RUM data from hundreds of e-commerce sites shows that the best conversion rate uplift occurs specifically below 1000ms, suggesting the five-year-old 2.5s threshold may no longer be ambitious enough for competitive sites.
This reframing — from “making things faster” to “making things instant” — reflects the convergence of several browser capabilities: Speculation Rules for predictive prerendering, BFCache for instant back/forward navigation, Service Workers for cached asset serving, and HTTP/3 with 0-RTT for faster connection establishment. The 2025 PerfPlanet calendar also highlights that Core Web Vitals cross-browser parity is finally arriving, with Safari adding LCP and INP support in late 2025 (joining Chrome and Firefox). This means we are moving toward a world where we can stop optimizing for a single browser engine and start optimizing for all users.
Resources:
- Web Performance 2025: The Shift from Optimization to Prediction — PerfPlanet
- The Performance Inequality Gap, 2026 — Infrequently Noted
- RUMCG — A Year in Review — PerfPlanet 2025
- Interop 2025 — Web Platform Dashboard
Choosing the Right Metrics for Your Project
Not every metric matters equally for every site. An e-commerce product page lives and dies by LCP and CLS (users need to see the product image quickly without it jumping around), while a SaaS dashboard with heavy interactions should prioritize INP. A content-heavy blog may find LCP and CLS most impactful for bounce rate, while rarely triggering complex interactions that would surface INP issues.
Start with field data, not lab data. A common mistake surfaced in DebugBear’s 100 site speed reviews in 2025 is chasing Lighthouse scores (lab-based) when CrUX field data tells a different story. One SaaS developer spent weeks reducing Total Blocking Time in Lighthouse even though their field INP was already healthy — effort wasted on the wrong metric. Use PageSpeed Insights to check CrUX data first, then use lab tools (Lighthouse, WebPageTest, Chrome DevTools) to diagnose the specific causes of field issues.
Beyond the Core Web Vitals, consider tracking these supplementary metrics: TTFB (Time to First Byte) as a server-side diagnostic; FCP (First Contentful Paint) as an early loading indicator; TBT (Total Blocking Time) as a lab proxy for INP; and Speed Index for overall perceived loading. For animations and smoothness, track frame rates and LoAF data. For SPAs, prepare for per-route metrics via the Soft Navigations API.
Resources: