Skip to content
Book a strategy call

Core Web Vitals in plain words

Three speed measures, what each one means, and the usual fixes.

Short answer. Core Web Vitals are three measures of real visitor experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Google treats LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 as good.

  • LCP, INP and CLS each measure a different frustration
  • Real-user data in Search Console beats a one-off test
  • Images, scripts and late-loading elements cause most problems

The three measures

Core Web Vitals are Google's way of putting numbers on how a page feels to use. There are three.

Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element, usually a hero image or a heading block, to appear. Google's published threshold for a good score is 2.5 seconds or less.

Interaction to Next Paint (INP) measures how quickly the page responds when someone taps, clicks or types. It replaced an earlier measure called First Input Delay. A good score is 200 milliseconds or less.

Cumulative Layout Shift (CLS) measures how much the page jumps around while loading, such as a button moving just as you tap it. A good score is 0.1 or less.

Google judges these at the 75th percentile of real visits, meaning three out of four visitors should have at least that experience.

How to read your scores

There are two kinds of data, and they answer different questions.

Field data comes from real visitors using Chrome. You will see it in the Core Web Vitals report in Search Console and in the Chrome UX Report. It is what Google actually uses, and it reflects real phones and real networks.

Lab data comes from a tool such as Lighthouse, which loads your page once in a controlled setting. It is excellent for finding causes and testing a fix before release, but it will not always match what visitors see.

Use field data to know whether you have a problem and lab data to work out why. A small site may not have enough traffic for field data, in which case lab tests on a mid-range phone setting are a fair stand-in.

The usual fixes

Most slow pages share a few causes.

For LCP:

  • Compress images and serve modern formats at the size they are shown.
  • Do not lazy-load the main image at the top of the page.
  • Reduce slow server responses with caching and a content delivery network.

For INP:

  • Remove or defer scripts you do not need, especially third-party tags.
  • Break up long tasks so the page can respond between them.
  • Avoid heavy work on every keystroke or scroll.

For CLS:

  • Set width and height on images and embeds so space is reserved.
  • Reserve room for banners, ads and cookie notices.
  • Load fonts in a way that avoids a visible jump.

Fix one template at a time, since the same layout usually drives many pages.

How much they matter

Google has said page experience is one of many signals, and relevance still comes first. A fast page with nothing useful on it will not rank. But among similar pages, speed can help, and it clearly helps visitors: slow pages lose people before they read a word.

Speed also affects answer engines. Tools that fetch pages live tend to move on from pages that respond slowly, so a quick, stable page gives them a better chance to read you.

Treat the three numbers as a health check rather than a score to chase. Aim for green, then spend your effort on content and clarity.

Not sure where you stand? Run the free AEO check for a first look, or book a strategy call and we will review your key templates together.

Want this done for you?

Start with the free check, or talk to us about a programme.

  1. A call about the goalThe budget, the deadline and what success looks like.
  2. A written scopeWhat we build, in what order, and the quote.
  3. Work in sprintsA demo at the end of each one.
Book a strategy call