# Core Web Vitals

Core Web Vitals are three Google metrics for real-world page experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability), measured from actual visits.

Also called: Web Vitals, LCP, INP, CLS, Page experience, Page speed.

## In short

- Three metrics: **LCP** for loading, **INP** for responsiveness, **CLS** for visual stability.
- Google measures them from real Chrome users, and a page passes when most visits meet the good thresholds.
- They are part of how Google ranks pages, but good content still matters more.
- Most problems come from heavy images, too much JavaScript, and content that shifts while loading.

## The three metrics

Google introduced Core Web Vitals in 2020 to describe, in a few numbers, whether a page feels fast and stable to the people using it. Each metric covers one part of that experience, and each has a threshold for good.

| Metric | What it measures | Good |
| --- | --- | --- |
| Largest Contentful Paint (LCP) | How long until the main content, often a hero image or headline, appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds visibly after a tap, click, or key press | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much visible content jumps around unexpectedly | 0.1 or less |

INP replaced an older metric, First Input Delay, in March 2024. It is stricter because it looks at responsiveness across the whole visit, rather than the first interaction alone.

## How they are measured

There are two kinds of data, and the difference causes a lot of confusion. **Field data** comes from real visitors using Chrome, collected in the Chrome UX Report. It is what Google uses for search. **Lab data** comes from a tool such as Lighthouse loading the page once in a controlled setting. It is useful for debugging but can differ from what users experience.

**Diagram: Field data and lab data.**

**Field data**
- Real visits from real devices
- Used by Google for ranking
- Assessed at the 75th percentile
- Needs enough traffic to appear

**Lab data**
- One simulated page load
- Available for any page, any time
- Good for finding causes
- Can miss problems real users hit

_Fix problems with lab tools, then confirm the improvement in field data a few weeks later._

A page passes when at least three quarters of visits meet the good threshold for each metric, which is what the 75th percentile means. You can check field data in PageSpeed Insights or the Core Web Vitals report in Google Search Console.

## Do they affect search rankings?

Yes, but modestly. Core Web Vitals are part of the page experience signals Google uses, and Google has said that relevant, helpful content still matters more. A fast page with weak content will not outrank a slower page that answers the question better.

The stronger reason to care is people. Slow pages and layouts that jump under someone's thumb lose visitors before they read anything, which shows up directly in sign-ups and sales on a [landing page](https://www.choie.co/glossary/landing-page). A [launch site](https://www.choie.co/services/launch-sites) from Choie is meant to explain the product in one screen and turn visitors into users, and a slow first screen works against both. Fast, clean HTML is also easier for AI crawlers to read, which supports [answer engine optimization](https://www.choie.co/glossary/answer-engine-optimization).

## The fixes that usually matter

- **Size and compress images.** Serve modern formats such as WebP or AVIF at the size they are displayed, and load the main image early.
- **Ship less JavaScript.** Heavy scripts slow loading and responsiveness. Remove unused libraries and third-party tags.
- **Reserve space.** Give images, embeds, and ads fixed dimensions so content does not shift when they load.
- **Render on the server.** Sending ready HTML, as frameworks such as [Next.js](https://www.choie.co/glossary/nextjs) can, gets content on screen sooner than building it in the browser.
- **Watch third-party scripts.** Chat widgets, analytics, and tag managers are frequent causes of poor INP.

> **Check the template, not the page.** Problems usually come from a shared layout or component, so fixing one template often fixes hundreds of pages at once.

## Common mistakes

- **Chasing a perfect Lighthouse score.** A lab score of 100 is nice, but field data is what counts.
- **Testing only on a fast laptop.** Many visitors use mid-range phones on mobile networks.
- **Adding scripts without checking cost.** Each new tool on the page has a performance price.
- **Fixing once and forgetting.** New features and content can undo the gains. Check after each major release.

Performance is easiest to get right while a [custom website](https://www.choie.co/glossary/custom-website) or app is being built, and harder to retrofit. At Choie, the same people design and write the code, so decisions like image sizes and layout stability are made once, on both sides.

## Common questions

### What are the Core Web Vitals thresholds?

Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, each met by at least three quarters of visits.

### What replaced First Input Delay?

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. INP measures responsiveness across every interaction on a page, where FID looked at the first one only.

### Do Core Web Vitals apply to mobile apps?

No. They are web metrics measured in the browser. Native mobile apps have their own performance measures, such as startup time and frame rate, tracked with platform tools.

### How do I check my site's Core Web Vitals?

Use PageSpeed Insights for a single URL, or the Core Web Vitals report in Google Search Console for the whole site. Both show field data from real users when there is enough traffic. A new site has no field data yet, so on a Choie build the Friday live link is the place to try each page on a mid-range phone before launch.

Related: [Next.js](https://www.choie.co/glossary/nextjs), [Custom website](https://www.choie.co/glossary/custom-website), [Landing page](https://www.choie.co/glossary/landing-page), [Answer engine optimization (AEO)](https://www.choie.co/glossary/answer-engine-optimization), [Web accessibility (WCAG)](https://www.choie.co/glossary/web-accessibility).

HTML: https://www.choie.co/glossary/core-web-vitals