Core Web Vitals Through a Usability Lens

The three metrics and their thresholds

Google's web.dev documentation defines three Core Web Vitals and a "good" threshold for each ¹.

The same documentation advises judging every metric at the 75th percentile of page loads and keeping mobile and desktop results apart ¹. In other words, a page meets a threshold when at least three in four visits experience a value at or better than it. Looking only at an average, or only at desktop, can hide a poor experience for a large group of visitors.

What each metric feels like

LCP: "Is anything happening?"

When the main content takes a long time to appear, visitors see a blank or half-built page. Some wait; some leave; some tap the back button and choose another result. A slow LCP is the visitor's first impression of the site's competence.

INP: "Did that work?"

INP replaced First Input Delay as a Core Web Vital in 2024. It captures the delay between an interaction and the next visual update. When a button does not react, people tap it again, which can submit a form twice or add two items to a cart. Slow responses feel like broken controls.

CLS: "It moved."

Layout shift is the most directly usability-related of the three. Content that jumps as images, ads or banners load makes people lose their place while reading, and can cause them to tap the wrong thing. A visitor reaching for "Cancel" who hits "Confirm" because the layout shifted has experienced a real error caused by a performance problem.

Field data and lab data

There are two ways to measure these metrics. Field data comes from real visits, collected by the browser and reported through sources such as the Chrome UX Report or your own monitoring. Lab data comes from a test run in a controlled environment, such as Lighthouse.

Field data is the better guide to what visitors experience, because it reflects real devices, networks and behavior. Lab data is useful for diagnosing causes and checking a fix before release. When the two disagree, investigate why rather than choosing the more flattering number.

INP, in particular, depends on real interactions, so lab tools can only approximate it. Treat lab results for responsiveness as hints.

Mobile checks after the Mobile-Friendly Test

For years, many site owners used Google's Mobile-Friendly Test and the Mobile Usability report in Search Console as a quick check. Search Engine Land reported that Google retired the Mobile Usability report, the Mobile-Friendly Test tool and its API in early December 2023, pointing site owners to Lighthouse instead ².

Lighthouse remains useful for technical checks, but neither it nor Core Web Vitals tells you whether a person can complete a task comfortably on a phone. Tap target size, form behavior with the on-screen keyboard and menus that are hard to find all need human review. Our mobile usability service covers those checks on real devices.

Common causes, from a usability point of view

Many of these causes come from third-party tools added over time: chat widgets, testing scripts, tag managers and advertising code. Each may be small on its own, but together they slow the page. Our A/B testing guide explains how client-side testing tools can add to layout shift.

Putting the metrics in context

Passing all three thresholds does not make a site easy to use, and failing one does not make it unusable. A fast page with confusing labels still fails visitors. Treat Core Web Vitals as one input in a usability review, alongside task-based testing and an expert review of content and flows.

When you report the metrics to non-technical colleagues, describe the experience rather than the number. "One in four phone visitors waits more than four seconds for the product photo to appear" is easier to act on than "mobile LCP at p75 is 4.1 seconds". Be careful to use your real figures; the example in this paragraph is illustrative.

Using the metrics in a usability study

Performance and usability findings support each other. When a participant in a session taps a button twice, hesitates in front of a blank page or loses their place as an image loads, note the moment and compare it with your field data for that page. If the session problem matches a metric that fails at the 75th percentile, you have both a human explanation and a measure of how widely the problem reaches. That combination is more persuasive to a development team than either piece of evidence alone, and it helps decide whether a fix belongs with designers, developers or both.