You should not need an engineering degree to read your own performance report. Yet the three metrics Google ranks your marketing site on are documented in language written for the people who fix them, not the people who own the revenue they move. Here is each one in plain English, where to find your own numbers, and why a site can ace two and fail the third.
Core Web Vitals Are Three Measurements, Not a Score
Core Web Vitals are three separate field measurements, not a single grade. Largest Contentful Paint covers loading. Interaction to Next Paint covers responsiveness. Cumulative Layout Shift covers visual stability. As of 2026, Google’s good thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, each measured at the 75th percentile of real visits (Google web.dev, 2026)[1].
The single-score habit is where most marketing teams go wrong. PageSpeed Insights shows a big colored number at the top, and the room reads that number as the verdict. It is not. The number is a weighted lab estimate. The three Vitals underneath it are the things that actually feed ranking, and they move independently. A page can render fast, hold still, and still freeze for half a second when someone taps the menu. Read the three, not the one.
Largest Contentful Paint: How Long Until the Page Looks Ready
LCP measures how long the largest visible element takes to render. On a marketing page that is usually the hero image or the headline block. Good is 2.5 seconds or less. Poor is anything over 4 seconds, which means visitors stare at half-loaded content while they decide whether to stay.
The business case for LCP is the cleanest of the three. In a 2021 Google case study, Renault improved LCP across 10 million visits and saw bounce rate fall 14 points and conversions rise 13%[2]. LCP is mostly a hosting, image, and server-response question. It is the metric a content delivery network actually helps with.
Interaction to Next Paint: How Long the Page Freezes After a Click
INP measures the lag between a tap, click, or keypress and the moment the page visibly responds. Good is 200 milliseconds or less. Poor is over 500. If a visitor taps your pricing toggle and nothing happens for half a second, that is bad INP, and they feel it as a site that is broken rather than slow.
INP replaced First Input Delay as a Core Web Vital on March 12, 2024 (Google web.dev, 2024)[3]. It is the newest and the hardest of the three to pass, because it tracks every interaction, not just the first. It is also the one a CDN cannot fix, because the lag lives in JavaScript running on the visitor’s own device. Bringing it down is involved enough to deserve its own dedicated guide.
Cumulative Layout Shift: How Much the Page Jumps
CLS scores how much visible content moves while the page loads. Good is 0.1 or less. Poor is over 0.25. The everyday cause is an image or ad slot loading without reserved space, shoving the text down exactly as the visitor reaches to click.
CLS is the cheapest to picture and the most annoying to experience. A reader goes to tap a link, the page lurches, and they hit a different one. The conversion cost is direct: misclicks, missed CTAs, and a subtle read of the site as unfinished. Unlike LCP and INP, CLS is usually a markup discipline problem, not a speed problem.
Field Data and Lab Data Measure Two Different Things
Field data is what real Chrome visitors experienced; lab data is a synthetic test run once from a controlled machine. Google ranks on field data, collected in the Chrome User Experience Report. Lab tools like Lighthouse are for debugging. A page can score green in the lab and red in the field, and the field is the one that counts.
This distinction is where most internal performance arguments stall. An engineer runs Lighthouse on a fast laptop with a wired connection, gets a 95, and reports the site is fine. The field data, drawn from real phones on real networks, says otherwise. When the two disagree, the field data wins, because that is the population Google measured and the population your buyers belong to. INP makes this concrete: it cannot be fully measured in a lab at all, because it depends on interactions a synthetic test never performs.
One caution about lab tools. In October 2025, Lighthouse 13 renamed several of its audit IDs, folding old checks into insight-based ones (the layout-shifts audit became cls-culprits-insight, for example), with no change to the underlying scoring (Google Chrome for Developers, 2025)[4]. If your team built a dashboard that queried audits by their old names, it may now be reading blanks. The Vitals themselves did not change. The labels on the lab tool did. Trust the field thresholds, not whatever a homegrown report claims this quarter.
Why Your Site Can Fail One Vital and Pass the Others
Each Vital has a different cause and a different fix, so failing one while passing two is the normal case, not a contradiction. LCP is about delivery and rendering. INP is about JavaScript on the device. CLS is about layout discipline. One team adding a CDN, another shipping a heavy tag, and a third forgetting an image dimension will each break a different metric.
This is why the “we added a CDN, we are covered” assumption fails. A CDN speeds up how fast bytes arrive, which helps LCP. It does nothing for INP, because the freeze happens in main-thread JavaScript after the bytes land, and nothing for CLS, because layout shift is decided by your markup. Teams buy the CDN, watch LCP improve, and stay puzzled that the overall score barely moves. The other two metrics had different owners all along.
Failures also tend to stack rather than arrive from one villain. One B2B SaaS site I audited took roughly 15 seconds to load on mobile, and there was no single catastrophic cause. It was the 15-second site that took seven fixes to reach one: seven medium problems compounding, each owned by nobody. The numbers say the same thing at the population level. In 2025, mobile pass rates were 62% for LCP, 77% for INP, and 81% for CLS, which means most failing sites are tripping on loading first and responsiveness second (HTTP Archive Web Almanac, 2025)[5].
Where Marketers Actually Read These Numbers
Two free Google tools show field data with no setup. Open pagespeed.web.dev, paste a URL, and read the field-data section near the top, not the lab score below it. Then open the Core Web Vitals report in Search Console for the site-wide view grouped by URL pattern. Both pull from CrUX, so both show what real visitors got.
The one move that surfaces most of the signal is the mobile toggle. In 2025, 97% of desktop pages passed INP but only 77% of mobile pages did, a 20-point gap (HTTP Archive Web Almanac, 2025)[5]. Your mobile visitors are getting a measurably worse site than your desktop visitors, and the desktop dashboard the team reviews each morning hides it. Toggle to mobile, compare the two, and the gap is your diagnostic.
Read the report monthly, the same cadence you would give any health metric. The point is not to become an engineer. It is to know whether the site Google measures is the site you think you are shipping. Once a marketing team can read its own Vitals, performance stops being an engineering mystery and becomes a number the team owns, which is the whole argument behind site speed is a marketing P&L line. The vocabulary on this page is the entry fee for that ownership.
Sources
- Google web.dev, Web Vitals – Official metric definitions and thresholds; good is LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 at the 75th percentile; poor is LCP >4s, INP >500ms, CLS >0.25 ↩
- Google web.dev, How Renault improved its bounce and conversion rates by optimizing Largest Contentful Paint – Data from 10M+ visits across 33 countries, Dec 2020-Mar 2021; a 1-second LCP improvement correlated with a 14-point bounce-rate drop and a 13% conversion lift ↩
- Google web.dev, Interaction to Next Paint becomes a Core Web Vital on March 12 – Official Google announcement, January 31 2024; INP replaced FID as a Core Web Vital on March 12 2024 ↩
- Google Chrome for Developers, What’s new in Lighthouse 13.0 – Published October 10 2025; audit IDs renamed to insight-based equivalents (layout-shifts became cls-culprits-insight); no change to performance scoring ↩
- HTTP Archive Web Almanac 2025, Performance chapter – Published January 15 2026; CrUX July 2025 field data across millions of sites; 48% of mobile sites passed all three Core Web Vitals; individual mobile pass rates 62% LCP, 77% INP, 81% CLS; INP mobile-desktop gap of 20 points ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures loading speed, INP measures how quickly the page responds to taps and clicks, and CLS measures how much the layout shifts while loading. Google evaluates all three from real Chrome users, and a page can pass two while failing the third. They are the page-experience metrics that feed both Google ranking and AI-assistant fetch-and-quote decisions.
As of 2026, Google's good thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, all measured at the 75th percentile of real visits. Poor begins at LCP over 4 seconds, INP over 500 milliseconds, and CLS over 0.25. Anything between good and poor is the needs-improvement band. The thresholds are identical on mobile and desktop, but mobile is far harder to pass.
No. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. FID only measured the delay before a visitor's very first interaction. INP measures the delay across every interaction in the session and reports close to the worst one. INP is structurally harder to pass, which is why many sites that were green on FID turned yellow or red overnight. See the INP optimization guide for the deep dive.
Yes, as one input among many. Google Search Central states that page-experience signals, including Core Web Vitals, are part of what its core ranking systems reward. The effect is not a hard penalty; it tips the scale between two otherwise comparable pages. In 2026 the same signal increasingly influences whether AI assistants fetch and cite a page, so slow performance now costs ranking and citation visibility together.
Field data is what real Chrome visitors actually experienced, collected in the Chrome User Experience Report (CrUX). Lab data is a synthetic test run once from a controlled environment, which is what Lighthouse produces. Google ranks on field data. Lab tests are useful for debugging, but a page can score green in the lab and red in the field. INP in particular cannot be fully measured in a lab because it depends on real user interactions.
