Core Web Vitals: How They Measure Page Experience

Core Web Vitals measure page experience through three user-centered signals: loading performance, responsiveness, and visual stability. They are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS); together, they show whether a page appears promptly, responds to input, and stays visually steady.

What Core Web Vitals Measure

These metrics focus on aspects of real page use that visitors can perceive. They do not grade every feature of a website, nor do they prove that a page is useful, accessible, secure, or well designed. Instead, they provide a consistent way to assess three important parts of the experience: how quickly the main content loads, how quickly the page reacts to interactions, and whether elements move unexpectedly.

• LCP: how long it takes for the largest visible image or text block in the viewport to render.
• INP: how responsive the page is to clicks, taps, and keyboard input across a visit.
• CLS: how much visible content shifts unexpectedly during loading and use.

The measures are complementary. A page can load its main content quickly but feel sluggish when someone opens a menu, or respond quickly while advertisements push text around. Looking at all three helps reveal different kinds of friction.

How LCP Measures Loading

LCP measures the render time of the largest qualifying content element visible in the viewport. Common examples include a hero image, a large product photo, or a prominent block of text. The metric starts when navigation begins and ends when that element is rendered, so it captures more than the time needed to download a file: server response, resource discovery, network transfer, and browser rendering can all matter.

Google’s current “good” threshold for LCP is 2.5 seconds or less. A result from more than 2.5 seconds up to 4 seconds needs improvement; over 4 seconds is poor. These thresholds are evaluated at the 75th percentile of visits, separately for mobile and desktop. That means at least three quarters of measured visits should meet the good threshold for a page or group of pages to pass.

For example, if the largest product image appears after 3.2 seconds, the page’s LCP is likely to reflect that delay. Improving image delivery or the time to first byte may help, but the right fix depends on which part of the loading process is slow.

How INP Measures Responsiveness

INP observes the delay between a user interaction and the next visual update on screen. It considers interactions such as clicking a button, tapping a control, or pressing a key, then reports a value intended to represent the page’s overall responsiveness during the visit. A visit may contain many interactions; the reported value is generally based on a high-percentile interaction delay, with an adjustment that prevents a single unusual outlier from dominating on pages with many interactions.

Good INP is 200 milliseconds or less. More than 200 milliseconds and up to 500 milliseconds needs improvement, while over 500 milliseconds is poor. Slow responses can come from long-running JavaScript, heavy rendering work, or other tasks that keep the browser’s main thread busy. A button may register a click immediately but still feel unresponsive if the page cannot update promptly.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before a browser began processing a visitor’s first interaction, so it did not capture the full response or later interactions. INP gives a broader view of responsiveness across a visit.

How CLS Measures Visual Stability

CLS quantifies unexpected layout movement. It is based on the impact fraction—the portion of the viewport affected by a shift—and the distance fraction—the distance elements move, relative to the viewport. The product of those fractions is a layout-shift score; CLS reflects the relevant shifts within a session window rather than simply adding every shift over an entire visit.

Good CLS is 0.1 or less. A score above 0.1 and up to 0.25 needs improvement, and above 0.25 is poor. A familiar cause is an image without reserved dimensions: text appears first, then moves down when the image loads. A banner inserted above an article can cause a similar shift. Movement caused by an intentional user action, such as opening a menu, is generally not treated the same way as an unexpected shift.

Developers can often reduce CLS by reserving space for images, video, embeds, and ads, and by avoiding inserting content above existing content without warning. Web fonts can also alter line wrapping and move text, so font loading choices may matter.

Field Data, Lab Tests, and Passing Thresholds

Core Web Vitals can be assessed with field data or lab tests, and the two answer different questions. Field data comes from real visits and reflects varied devices, network conditions, and user behavior. Chrome’s publicly available real-user data, for example, is aggregated and anonymized; it does not represent every site or every visitor. Lab tools run controlled tests that help reproduce problems and compare changes, but a simulated visit cannot capture the full range of real-world conditions.

For search-related Core Web Vitals assessment, the good thresholds are judged at the 75th percentile of field visits. A site should therefore avoid treating one fast test run as proof that everyone has a good experience. Mobile and desktop performance can differ substantially, and page templates may behave differently from one another.

Passing Core Web Vitals does not guarantee high search rankings. Google has described page experience as one consideration among many; relevant, helpful content remains important. The metrics are best used as experience diagnostics, not as a complete quality score or a substitute for usability testing.

Finding and Fixing Common Problems

Start by checking field reports for the affected device category and page group, then use a lab test or browser performance tools to investigate specific pages. Prioritize issues that affect many visits and identify the element or interaction responsible before changing code.

• High LCP: inspect server response time, render-blocking resources, and the loading priority, size, and format of the main image or text.
• High INP: inspect slow interactions and long main-thread tasks; reduce unnecessary JavaScript work and break up tasks where appropriate.
• High CLS: check for images or embeds without reserved dimensions, late-inserted content, and font changes that alter layout.

Recheck both lab results and field data after a change. A fix that improves one metric can affect another: for instance, delaying content until after a user action might avoid an early layout shift but harm responsiveness. Also remember that field data updates over time and may not change immediately after a deployment.

Frequently Asked Questions

What are the three Core Web Vitals?
LCP measures loading, INP measures interaction responsiveness, and CLS measures unexpected visual movement.

What are good Core Web Vitals scores?
Good results are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.

Are Core Web Vitals the same as page speed?
No. LCP concerns a key loading milestone, but INP and CLS measure responsiveness and visual stability. Together they cover more than download speed alone.

Why do lab and field scores differ?
Lab tests use controlled conditions, while field scores reflect real visits across different devices, networks, and interactions. A particular user’s experience may differ from either summary.

Do Core Web Vitals determine Google rankings?
No single metric guarantees a ranking. Core Web Vitals are part of page-experience considerations, alongside many other signals and the relevance and usefulness of a page.

Related

• ESP32 E-Paper Flight Tracker: Build One for Your Desk
• Phone Scan Old Photos Clean? What to Know
• SCP Commands Examples for File Transfer