LCP, INP, CLS:
the numbers users feel.
Buyers increasingly ask for frontend performance alongside API uptime, and the Core Web Vitals are the shared yardstick. This guide covers the thresholds, where the numbers come from, and how to improve each one.
Last updated Published by TryTrustableNot legal advice
Core Web Vitals are Google's three metrics for real-world page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. INP replaced First Input Delay (FID) on 12 March 2024. The pass or fail comes from field data (the Chrome UX Report); lab tools such as Lighthouse help you find and fix the causes.
What are Core Web Vitals?
Core Web Vitals are a set of three metrics Google uses to describe the experience of loading and using a web page: loading speed, responsiveness and visual stability. They are part of the wider Web Vitals programme, and Google Search uses them as part of its page experience signals. For a SaaS company they matter twice: on the marketing site for search and conversion, and in the product, where slow and jumpy screens generate support tickets.
Core Web Vitals thresholds: good, needs improvement, poor
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP: Largest Contentful Paint | Loading: when the largest image or text block is rendered | 2.5 s or less | Over 2.5 s up to 4 s | Over 4 s |
| INP: Interaction to Next Paint | Responsiveness: delay from a click, tap or key press to the next frame, across the visit | 200 ms or less | Over 200 ms up to 500 ms | Over 500 ms |
| CLS: Cumulative Layout Shift | Visual stability: unexpected movement of content | 0.1 or less | Over 0.1 up to 0.25 | Over 0.25 |
Thresholds from web.dev, assessed at the 75th percentile of page loads, separately for mobile and desktop.
The 75th percentile matters: a page passes only if at least three in four visits meet the good threshold, so a fast experience on your office broadband says little about a customer on a mid-range phone.
INP replaced FID: what changed?
On 12 March 2024, Interaction to Next Paint replaced First Input Delay as the Core Web Vital for responsiveness. FID measured only the delay before the browser began handling the first interaction. INP observes the interactions across the whole visit and measures through to the next frame being painted, so it catches slow handlers and heavy re-renders that FID missed. Single-page apps with heavy JavaScript tend to find INP harder to pass than FID was.
Field data vs lab data (CrUX vs Lighthouse)
| Field data | Lab data | |
|---|---|---|
| Source | Real Chrome users, via the Chrome UX Report (CrUX), or your own real-user monitoring | A simulated load in a controlled environment, such as Lighthouse |
| In PageSpeed Insights | The real-user section at the top (trailing 28 days) | The Lighthouse diagnostics below it (one run, now) |
| Includes INP? | Yes | No: there is no real user interacting. Total Blocking Time is the lab signal for the main-thread work behind poor INP |
| Good for | Whether you pass Core Web Vitals; trends | Finding causes; catching regressions before release; testing pages with too little traffic for CrUX |
| Limits | Needs enough traffic; lags by up to 28 days; public pages only | One device and network profile; can differ from what users see |
PageSpeed Insights shows both on one page: field data from CrUX at the top when Google has enough data for the URL or origin, and a Lighthouse lab run below with a performance score (90 and above is good, 50 to 89 needs improvement, below 50 is poor). The lab score is not a Core Web Vitals pass; the field assessment is.
How to improve LCP, INP and CLS
| Metric | Common causes | Fixes that usually work |
|---|---|---|
| LCP | Slow server response, render-blocking CSS and JavaScript, a large hero image discovered late, client-side rendering of the main content | Cut time to first byte (caching, CDN, faster queries); serve the LCP image in a modern format at the right size and preload it or give it high fetch priority; do not lazy-load the LCP image; inline critical CSS; render the main content on the server |
| INP | Long JavaScript tasks on the main thread, heavy event handlers, large re-renders, third-party scripts | Break up long tasks and yield to the main thread; do less work in handlers and defer the rest; reduce re-render scope; load third-party scripts later; ship less JavaScript |
| CLS | Images and embeds without dimensions, ads and banners injected above content, web fonts swapping, late-loading UI | Set width and height or aspect-ratio on media; reserve space for banners and embeds; avoid inserting content above what the user is reading; use font-display and matched fallback fonts; animate with transform |
How to measure Core Web Vitals in a SaaS app
- Public pages (marketing site, docs, sign-in): PageSpeed Insights and Search Console show field data once you have enough Chrome traffic.
- Logged-in product screens: CrUX publishes page-level data only for public pages with enough traffic, so add real-user monitoring with the open-source
web-vitalsJavaScript library and send the values to your analytics. - Before release: run Lighthouse in CI or on a schedule against key pages, with a budget, so a regression is caught before users feel it.
How TryTrustable's frontend audits use PageSpeed Insights
TryTrustable runs frontend audits through the Google PageSpeed Insights API, which runs Lighthouse on a public URL using the mobile profile. Each run records the Lighthouse performance score, LCP, CLS, First Contentful Paint, Total Blocking Time, Time to Interactive and Speed Index, and checks them against the SLO you set (a minimum score and a maximum LCP). Runs can be manual, hourly, daily or on deploy, and every result is stored as evidence next to your API load tests.
Be clear on what that is: lab data. It does not read CrUX field data and cannot measure INP, so use PageSpeed Insights or Search Console for the field assessment and real-user monitoring inside the app. See performance testing for the full feature, and the SLA, SLO and SLI guide for turning these numbers into targets.
The things people ask us
What are the three Core Web Vitals?
Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability).
What is a good LCP score?
2.5 seconds or less at the 75th percentile of page loads. Over 4 seconds is poor.
What is a good INP score?
200 milliseconds or less at the 75th percentile. Over 500 milliseconds is poor.
When did INP replace FID?
On 12 March 2024. FID is no longer a Core Web Vital.
Why do PageSpeed Insights lab and field results differ?
Lab data is one simulated load on a fixed device and network. Field data is the 75th percentile of real Chrome users over the last 28 days, on their devices and networks.
Does TryTrustable measure INP?
No. Its frontend audits use Lighthouse lab data through PageSpeed Insights, which cannot measure INP. It records Total Blocking Time, the lab signal for the same problem, alongside LCP and CLS.
Keep frontend performance on the record.
Thirty minutes: schedule a PageSpeed audit and an API load test against your own targets, and see the results land as evidence.