Guides · · Agile Media Agency

Core Web Vitals in plain words

Three measurements Google uses to describe how a page feels to visitors: how fast it shows up, how fast it responds, and whether it jumps around.

On this page
  1. What they are
  2. Loading: Largest Contentful Paint (LCP)
  3. Responding: Interaction to Next Paint (INP)
  4. Stability: Cumulative Layout Shift (CLS)
  5. How a page passes
  6. Field data and lab data
  7. How common is passing
  8. Does it matter
  9. What to do

What they are

Core Web Vitals are three measurements of how a web page feels to a real visitor. Google defines them and publishes the targets (web.dev). They answer three simple questions:

  • Does the main part of the page show up quickly?
  • Does the page answer when I tap or click?
  • Does the page stay still while I read it?

Loading: Largest Contentful Paint (LCP)

LCP is the time until the biggest thing in view has appeared. That is usually a large photo, a video poster or a big block of text (web.dev).

Good is 2.5 seconds or less.

Slow LCP often comes from a slow server, a large image that arrives late, or a web font that holds the text back (web.dev, optimizing LCP). The first thing to look at is your top-of-page photo.

Responding: Interaction to Next Paint (INP)

INP measures the wait between a tap, click or key press and the moment the page visibly reacts (web.dev). It looks at the whole visit, not one click.

Good is 200 milliseconds or less.

Poor INP usually means the page is busy running scripts and cannot answer you yet (web.dev). INP replaced an older measure called First Input Delay, and became a stable Core Web Vital in 2024 (web.dev).

Stability: Cumulative Layout Shift (CLS)

CLS counts how much the page jumps around while you look at it (web.dev). You have felt it: you go to tap a button and an ad pushes it down.

Good is 0.1 or less.

Typical causes are images with no set size, fonts that change size when they load, and ads or widgets that resize after loading (web.dev).

How a page passes

Google looks at what real visitors experienced, takes the 75th percentile (so three visits in four were at least this good), and splits mobile from desktop. A page passes only if it meets all three targets (web.dev).

Field data and lab data

There are two kinds of numbers, and they can disagree (PageSpeed Insights docs):

  • Field data comes from real Chrome users over the previous 28 days. It shows what visitors actually lived through. A small site may have too little traffic to have any.
  • Lab data comes from one simulated test run. It is good for finding problems, but one run can vary from the next.

Our test shows both when they exist, and labels which is which.

How common is passing

Not as common as you might think. In the 2025 HTTP Archive Web Almanac, 48% of mobile sites passed all three, and 56% on desktop. On mobile, loading was the weak spot: 62% of sites had a good LCP (Web Almanac, 2025).

If your site fails, you are in good company, and it is fixable.

Does it matter

It matters first for your visitors: a fast, steady page is nicer to use. We make no promise about search rankings, and no tool can. What we can say is that a site that passes is a nicer site to use.

What to do

  1. Test your site. It is free.
  2. Look at mobile first. In the Almanac, mobile pass rates were lower than desktop.
  3. Fix the biggest cause first. For many sites that is one oversized image or one heavy script.
  4. Re-test after about a month. Field data covers 28 days, so it lags behind your changes.

Some problems come from the platform itself, and cannot be fixed with a setting. In that case Agile Media Agency can rebuild the site to be fast from the start. Tell us about your site.

Test your siteAll guides