Core Web Vitals in plain words: the three numbers that judge your page

Tomás sells refurbished espresso machines from a workshop behind his flat. His new site looks lovely on his laptop. On a Sunday morning he opens it on his phone, on the train, on one bar of signal.

The logo arrives. Then a grey box where the hero photo should be. Then, finally, the machine. He taps “See prices” and nothing happens for a beat, so he taps again. Just as he does, a “Free delivery this month” strip slides in at the top and his thumb lands on it instead.

Nothing is broken. Every part of the page eventually works. But in those few seconds his site failed all three of the tests Google uses to describe how a page feels to real people.

Tomás and his shop are imagined. The metrics, thresholds, studies and documentation below are real.

Three numbers, three feelings

Core Web Vitals are Google's attempt to turn three everyday frustrations into numbers you can track. Each one corresponds to something a visitor notices without knowing the word for it.

• Largest Contentful Paint (LCP) asks: how long until the main thing on the screen appears? It is the “is this page actually loading?” feeling.

• Interaction to Next Paint (INP) asks: when I tap, click or type, how long until the screen shows a response? It is the “did that work?” feeling.

• Cumulative Layout Shift (CLS) asks: does the page jump around while I am reading or about to tap? It is the “wait, where did it go?” feeling.

Each metric has two thresholds that split results into good, needs improvement and poor. These are the official numbers from web.dev, Google's developer documentation.

One piece of history matters, because older articles are still everywhere. The responsiveness metric used to be First Input Delay (FID), which only timed the wait before the first tap was handled. Google announced in May 2023 that INP would replace it, and the switch happened on 12 March 2024. If a tool or agency report still talks about FID, it is out of date.

Do this: open PageSpeed Insights, paste your homepage address and look at the top box. If it shows real-user data, write down your three numbers for mobile before reading on.

LCP: when the main thing appears

LCP reports when the largest image, text block or video visible in the first screen finished rendering, measured from the moment the visitor started navigating to the page. On most landing pages that element is the hero photo or the headline.

Why the largest element? Because it is a decent proxy for “the page has shown me what it is about”. A spinner or a logo appearing quickly does not help much if the thing you came for is still a grey rectangle.

Good is 2.5 seconds or less. Poor is more than 4 seconds.

Google's LCP optimization guide splits the wait into four parts, and the split tells you where to look. Usually the surprise is not the download itself. The guide notes that download time is often not the main bottleneck. More often the browser simply finds out about the hero image too late.

Quick fixes for LCP

• Make the hero image discoverable in the HTML. An image injected by JavaScript or set as a CSS background is found late. A plain <img> in the markup is found immediately. If it must live in CSS, add <link rel="preload"> for it.

• Add fetchpriority="high" to the hero image, and only to that one. It tells the browser this download matters more than the others.

• Never lazy-load the hero. The guide is blunt: lazy-loading the LCP image will always add unnecessary delay. Lazy-load what is below the fold instead.

• Send the right size. Use srcset and sizes so a phone does not download a 3,000-pixel image, and a modern format such as WebP or AVIF.

• Speed up the server response. Cut redirects, cache pages at a CDN where you can. Every millisecond before the first byte is added to everything after it.

• Remove render-blocking code. Defer scripts in the <head> and keep the critical CSS small. Fonts, sliders and chat widgets loaded first are classic culprits.

INP: when a tap gets an answer

INP measures how quickly the page visibly responds to clicks, taps and key presses, across the whole visit. Hovering and scrolling do not count. At the end of the visit, the page reports roughly its worst interaction: web.dev explains that one in every 50 interactions is ignored as an outlier, so a single freak hiccup on a long session does not define you.

Good is 200 milliseconds or less. Poor is more than 500 milliseconds.

The key word is next paint. INP does not care whether your code finished its work. It cares when the screen changed so the person could see something happened. That is why a button that shows a pressed state immediately, then does the heavy work, feels fast even if the work takes a second.

Most poor INP comes from the main thread being busy. Browsers do almost everything a page needs, running JavaScript, working out layout, painting, on one main thread. While a big script is running, a tap has to wait in line. Google's guide to long tasks defines a long task as anything over 50 milliseconds.

Quick fixes for INP

• Remove what you do not need. Every third-party script (chat, heatmaps, three analytics tools, an A/B testing library) competes for the same main thread. The fastest JavaScript is the script you do not load.

• Break up long tasks. Split a big job into smaller pieces and let the browser breathe between them. The new scheduler.yield() API exists for exactly this. At the time of writing, web.dev lists support in Chrome, Edge and Firefox but not Safari, so use it with a setTimeout fallback.

• Show feedback first, work second. Update the button (pressed state, spinner, “Adding…”) before starting expensive work, so the next paint comes quickly.

• Do less on every keystroke. Search boxes and filters that re-render the whole page on each letter are common offenders. Debounce, or update on blur.

For a simple landing page, INP is usually the easiest of the three to pass, because there is not much JavaScript to begin with. It goes wrong when a page builder, a cookie banner, a chat widget and a tag manager all wake up at once. For how fast “fast” has to feel, see Speed and feedback.

CLS: when the page holds still

CLS measures unexpected movement. Every time something visible shifts position without the visitor causing it, the browser scores the shift by two things: how much of the screen was affected, and how far things moved. web.dev gives the formula plainly: layout shift score = impact fraction × distance fraction.

Shifts that happen in quick succession are grouped into a “session window” (gaps under a second, five seconds maximum), and CLS is the worst window of the visit. Good is 0.1 or less. Poor is more than 0.25.

Shifts that you cause on purpose do not count. If something moves within 500 milliseconds of a tap, click or key press, such as an accordion opening, the browser marks it as expected and leaves it out. CLS is about the page moving on its own.

Quick fixes for CLS

• Give every image and video width and height attributes (keep height:auto in CSS), or reserve the box with CSS aspect-ratio. The browser can then hold the space before the file arrives.

• Reserve space for anything that loads late: ads, embeds, cookie notices, review widgets, “free delivery” strips. Use min-height on the container, or overlay the element so it does not push content.

• Insert new content below, not above. web.dev notes that content injected near the top of the viewport causes bigger shifts. A banner at the bottom of the screen or a “Load more” button does not shove what someone is reading.

• Tame web fonts. When a custom font swaps in, text can reflow. Preload the key font, pick a fallback with similar proportions (or use size-adjust), or use font-display: optional so the font is only used if it arrives in time.

• Animate with transform. Moving things with top or left counts as layout shift. Transforms do not.

The 75th percentile rule

Your page does not have one LCP. It has thousands: one per visit, depending on the phone, the network, the cache and the weather. So Google needs a rule for turning a crowd of measurements into a single verdict.

The rule is the 75th percentile, measured separately for mobile and desktop. Sort all the visits from fastest to slowest and look at the one three quarters of the way along. If that visit meets the “good” threshold, the page passes. In plain words: at least three out of four visits must have a good experience.

This rule explains two things site owners find confusing. First, why your page can “fail” even though it loads fast for you: you are on good Wi-Fi with a recent phone, and the 75th-percentile visitor is not. Second, why you cannot fix it by testing harder on your own device. You fix it by making the slowest quarter of visits better: lighter pages, smaller images, less JavaScript.

Do this: in PageSpeed Insights, switch between Mobile and Desktop. If mobile fails and desktop passes, your problem is weight and CPU, not your server.

Field data versus lab data

There are two kinds of measurement, and mixing them up causes most of the confusion around Core Web Vitals.

Field data comes from real visitors. Google's source is the Chrome UX Report (CrUX), built from Chrome users who have opted in to sharing usage statistics. Only pages and sites that are publicly discoverable and popular enough are included, so a brand-new or low-traffic page may have no field data at all. Search Console uses the last 28 days of this data.

Lab data comes from a single simulated visit, usually by Lighthouse, on a fixed device and network. It is repeatable and detailed, which makes it great for debugging. But as web.dev's article on lab and field differences explains, it cannot reproduce real caches, real devices or real people clicking. A lab test has nobody tapping, so for responsiveness it reports Total Blocking Time (TBT) as a diagnostic stand-in for INP.

Search Console has one more rule worth knowing: a group of pages gets the status of its worst metric. Two greens and a red is a red.

When the two kinds disagree, believe the field. Lab scores are the thermometer you use in the workshop; field data is the weather your customers actually live in. And note the lag: because field data covers 28 days, a fix you ship today takes weeks to show fully.

How much Google really cares

Here is where a lot of agencies oversell. So let us read what Google itself says.

Google's page experience documentation states that Core Web Vitals are used by its ranking systems. In the same breath it says that Google “always seeks to show the most relevant content, even if the page experience is sub-par”, that good scores do not guarantee top rankings, and that chasing a perfect score may not be the best use of your time.

A good page experience doesn't override having great, relevant content.

That line is from Google's 2020 announcement of the page experience signals. The same post said page experience becomes much more important when many pages are similar in relevance. Read together, the honest summary is: Core Web Vitals work like a tie-breaker, not a trump card. Relevance and quality win first. Among comparable pages, the faster, steadier one has an edge.

For a small business that is still a real reason to care, but not the main one. The main one is the person on the train with one bar of signal. They do not know what LCP stands for. They just leave, or tap the wrong thing.

What faster pages earned

Google publishes case studies on web.dev of companies that improved their vitals. Keep two caveats in mind: they are chosen by the company that invented the metrics, and most are before-and-after comparisons reported by the businesses themselves, not peer-reviewed experiments. Vodafone's is the exception: an A/B test.

What these do show: in real businesses, the work that improves these metrics has coincided with measurable gains, and in one controlled test it caused them. What they do not show: that your site will see the same percentages, or that every millisecond is worth the same.

And how common is passing? The HTTP Archive Web Almanac 2025, using July 2025 data, found:

So roughly half of the web fails on phones. Passing is not a formality. It is a small, real advantage over the average competitor.

What to change tomorrow

1. Get your real numbers

   Run your homepage and your main landing page through PageSpeed Insights. Note the mobile field data if it exists. If there is none, your traffic is too low for CrUX; use the lab numbers as a guide and fix the obvious.

2. Find your LCP element and help it

   Lighthouse names the LCP element. If it is your hero image: plain <img> in the HTML, fetchpriority="high", no lazy-loading, properly sized WebP or AVIF.

3. Put dimensions on every image

   Add width and height attributes to all images and embeds. It is the cheapest CLS fix there is.

4. Reserve space for late arrivals

   Banners, cookie notices, review widgets and ads get a fixed-height slot or sit on top of the page instead of pushing it.

5. Audit your third-party scripts

   List every script on the page and who asked for it. Remove the ones nobody can defend. Defer the rest. This helps LCP and INP at once.

6. Make every button answer instantly

   A pressed state or “Sending…” label on tap, before any heavy work. Real speed and perceived speed both improve.

7. Check again in a month

   Field data covers 28 days. Put a reminder in your calendar and judge the fix by Search Console, not by one more lab run.

Tomás's fix, in the end, took an afternoon: a properly sized hero image marked as high priority, a reserved slot for the delivery strip, and two forgotten tracking scripts deleted. The machine now appears before the train leaves the station. And when he taps “See prices”, his thumb lands where he meant it to.

Sources

1. Google (web.dev). Web Vitals. Consulted for the three metrics, the “good” thresholds and the 75th-percentile assessment.
2. Google (web.dev). Largest Contentful Paint (LCP). Definition, eligible elements, 2.5 s and 4 s thresholds.
3. Google (web.dev). Interaction to Next Paint (INP). Definition, the three phases of an interaction, the outlier rule, 200 ms and 500 ms thresholds.
4. Google (web.dev). Cumulative Layout Shift (CLS). Score formula, session windows, the 500 ms user-input exclusion, 0.1 and 0.25 thresholds.
5. Google Search Central Blog (2023). Introducing INP to Core Web Vitals. Announcement and the update confirming the change on 12 March 2024; see also web.dev, INP is officially a Core Web Vital.
6. Google (web.dev). Optimize Largest Contentful Paint. The four LCP subparts and recommended fixes (discoverability, fetchpriority, no lazy-loading, render-blocking resources).
7. Google (web.dev). Optimize long tasks. The 50 ms long-task definition, scheduler.yield() and its browser support table.
8. Google (web.dev). Optimize Cumulative Layout Shift. Fixes for images, embeds, injected content, fonts and animations.
9. Google (web.dev). Why lab and field data can be different. Lab vs field, TBT as a diagnostic for INP.
10. Chrome for Developers. CrUX methodology. Opted-in users, discoverability and popularity requirements.
11. Google Search Console Help. Core Web Vitals report. CrUX source, 28-day window, URL groups, worst-metric status rule.
12. Google Search Central. Understanding page experience in Google Search results. Ranking statements quoted above.
13. Google Search Central Blog (2020). Evaluating page experience for a better web. Relevance vs page experience.
14. Google (web.dev). Case studies: Vodafone (2021), redBus (2023), The Economic Times (2023), Yahoo! JAPAN News (2021). Figures as reported by the companies.
15. HTTP Archive (2025). Web Almanac 2025: Performance. Pass rates from July 2025 CrUX data.

Sources checked 18 October 2026. Thresholds and tool behavior change; check web.dev for the current definitions. Tomás, his shop and the visit timings in the figures are illustrative; the case-study numbers are as published by web.dev.