Core Web Vitals in plain English, and whether yours are bad

Somebody tells you your Core Web Vitals are failing. Maybe it came from an email from a stranger selling speed fixes, maybe from a red banner in Google Search Console. The report is full of three-letter codes and the colour is red, so it sounds urgent.

Before you spend anything, it helps to know what the three measurements are. Each one describes something a visitor sees or feels, and once you know which, the report stops being frightening.

Loading: LCP

LCP stands for Largest Contentful Paint. Ignore the name. It is the time between someone tapping your link and the biggest thing on the screen appearing, usually the main photo at the top or the first big block of text.

It is the moment the visitor thinks “right, it has loaded”. Before that they are looking at white, or at half a page.

Google calls anything up to 2.5 seconds good, and anything over 4 seconds poor. On a small business site the cause is nearly always one of two things: a slow server that takes a second or more before it sends anything, or a huge photo at the top of the page. Our piece on why your website is slow covers how to tell which.

Responding: INP

INP is Interaction to Next Paint. It measures what happens after the page has loaded, when the visitor taps the menu button, opens a dropdown or presses “Send” on a form, and how long the screen takes to react.

You know the bad version. You tap the menu on your phone, nothing happens, you tap again, and then it opens and closes in quick succession. The page was busy running scripts and ignored you.

Good is 200 milliseconds or under, about the time it takes to blink. Poor is over 500. The usual cause is too much JavaScript: chat widgets, sliders, tracking tags and page-builder scripts all queuing for the same attention. A plain brochure site with a contact form rarely has a problem here. A site with six plugins each adding their own scripts often does.

Stability: CLS

CLS is Cumulative Layout Shift, and it is the easiest to understand because everybody has been caught by it. You go to tap a link, an advert or a cookie banner loads above it, the page jumps down, and you tap the wrong thing.

Google scores it as a number, and 0.1 or under is good. Over 0.25 is poor. The usual causes are images without set dimensions, so the browser does not know how much room to leave, fonts that swap in late and change the line lengths, and banners that push content down after it has loaded.

On a booking or contact page this one costs real money. A visitor who hits the wrong button because the page moved does not try twice.

Where to read your own numbers

Run your home page through PageSpeed Insights and scroll past the big score. The part you want is headed Discover what your real users are experiencing, and it shows LCP, INP and CLS measured from real visitors on real phones over the last 28 days.

That is called field data, and it is the figure Google uses. The lab score further down is a single test run from a data centre, which is useful for finding faults and says little about how your visitors fare.

Search Console has the same data under Experience, then Core Web Vitals, split by phone and desktop and grouped by page type.

One thing catches small sites out. Google only reports field data when enough real visitors have come through Chrome. A site with a few hundred visits a month often shows “no data available”. That is not a fault. It means Google has too little to measure, and the lab test is all you have to go on.

A page passes when 75 per cent of visits meet the good threshold for all three. One bad measurement fails the page.

How much it matters

Less than the emails suggest, and more than nothing.

Google has said for years that these measurements feed into ranking, as part of a wider set of page experience signals. The effect is small. A page with a better answer to the search beats a faster page with a worse one, and if you sit on page three for “solicitor Skipton”, fixing your LCP will not move you to page one.

Where it does matter is as a tie-breaker between pages that are otherwise close, and as a measure of whether visitors give up. Slow loading and jumping pages cost you people who had already found you. You will not see them in your analytics as a lost enquiry. They are missing.

So the sensible order is this. Read your field data once. If all three are green, stop and spend the time on something else. If one is red, fix that one, and start with LCP, because it is the most common failure and the one visitors notice first. We took one site from a 4.15 second average load to 0.52 seconds by changing where it was hosted and touching almost nothing on the page.

What to do next

Open PageSpeed Insights, find the real-user section for your home page, and write down the three numbers. If they are inside the limits above, you are done for now. If they are not, you will at least know which of the three to ask about, which beats being told that “your site needs optimising”.

Fixing the cause is part of what we do on our Care & Hosting plan, and if you would rather someone read the numbers for you, the free website review gives you all three, with a plain note on what is behind any that fail.