Core Web Vitals, explained without the jargon

The three measurements, in plain terms

Each has a threshold Google publishes for what counts as good. The thresholds below are Google's own rather than our interpretation of them, and they are measured at the 75th percentile of page loads — meaning three-quarters of real visits have to beat the number before a page passes.

That percentile detail matters more than it sounds. A site can feel fine on your laptop and still fail, because the measurement is taken across everybody who visited, including the person on a five-year-old Android phone on a train.

Largest Contentful Paint — how soon the main thing appears

The time until the biggest visible element has rendered, usually a hero image or a block of heading text. Google's threshold for good is 2.5 seconds or less, and over 4 seconds is classed as poor. This is the one most often failed and usually the one worth fixing first, because it is what somebody experiences as the site being slow.

Interaction to Next Paint — how soon it responds when you tap

The delay between somebody tapping and the page visibly doing something about it. Good is 200 milliseconds or less; over 500 is poor. It replaced an older measurement called First Input Delay in March 2024, and it is stricter, because it looks at every interaction on the page rather than only the first. Sites heavy with scripts tend to fail this one.

Cumulative Layout Shift — how much the page jumps about

A score for how much content moves after it has been drawn, which is the thing that makes you tap the wrong link because a banner loaded above it. Good is 0.1 or less; over 0.25 is poor. It is a score rather than a time, and it is very often caused by images and adverts with no width and height set, so the browser cannot reserve space for them.

Why two tools give you two different answers

This is the most common source of confusion about Core Web Vitals, and it is not a fault in either tool. There are two different kinds of measurement, answering two different questions.

Lab data is a single test run on demand, on a simulated device and connection, in a controlled environment. It is repeatable and it tells you what is wrong. Field data is collected from real Chrome users who opted into sharing it, aggregated over the previous 28 days. It is what Google actually uses, and it tells you what people are really getting.

So a page can score well in a testing tool and fail in Search Console, and both are correct. The lab run happened on a good connection; the field data includes your visitors on bad ones. When the two disagree, the field data is the one that counts and the lab data is the one that tells you what to change.

If you have no field data at all

Sites below a certain amount of traffic never accumulate enough real-user samples to be reported, so Search Console shows nothing. This is not a failure and there is nothing to fix. It does mean the only measurement available to you is the lab one, and its exact numbers should be read as indicative rather than literal.

If the lab score is good and the field score is not

Usually one of three things: your real visitors are on slower connections than the test simulates, a page that is fast for a first-time visitor is slow for a logged-in one, or one template is dragging the average down while the home page is fine. Field data is grouped by URL, so look at which group is failing rather than assuming it is the whole site.

What actually fixes each one

The advice below is ordered by how often it turns out to be the answer rather than by how sophisticated it sounds. In most cases the problem is one large thing rather than many small ones.

For a slow Largest Contentful Paint, look at the biggest image first

An uncompressed hero image is the most common single cause. A photograph served at 4000 pixels wide and displayed at 800 is downloading roughly twenty-five times the data needed. Serving it at the size it is displayed, in a modern format, and not lazy-loading the one image that is visible immediately, fixes a large share of failures on its own.

If the server itself is slow, no amount of image work will help

Time to First Byte is how long the server takes to start responding at all, before the browser has anything to draw. If that is already over a second, it is the ceiling on everything else. On shared hosting this is often the honest answer, and the fix is caching or a better host rather than anything on the page.

For layout shift, set dimensions and reserve space for anything injected

Give every image a width and height attribute, or a CSS aspect ratio, so the browser knows how much room to leave before the file arrives. The other frequent culprit is anything inserted after load — cookie banners, adverts, chat widgets — which should be given reserved space rather than allowed to push the page down.

For interaction delay, the answer is almost always less JavaScript

The browser can only respond to a tap when it is not busy doing something else. Long tasks blocking the main thread create the delay, and they usually come from third-party scripts rather than your own code. Auditing what you actually load, and removing the tag somebody added for a trial two years ago, is more effective than optimising what remains.

How much do they affect rankings, honestly

Less than the volume of writing about them suggests. Google has described page experience as one signal among many and has said repeatedly that it does not override relevance — a slow page that answers the question will still beat a fast page that does not.

The realistic framing is a tiebreaker. Where two pages are otherwise comparable, the better experience can win. Where they are not comparable, speed will not close the gap. If your pages are not ranking at all, Core Web Vitals are very unlikely to be the reason, and time spent there is time not spent on the thing that is.

The stronger argument for fixing them has nothing to do with Google. A page that takes six seconds on a phone loses people before it finishes loading, and that costs you regardless of where you rank. Treat the measurements as a proxy for whether your site is pleasant to use and the ranking question mostly takes care of itself.

What a scan can and cannot tell you

An automated scan measures the lab side properly: it loads your pages in a real browser, records what rendered and when, and points at the specific image or script responsible. That is where a tool genuinely saves time, because working out which of forty requests is the blocking one is tedious and mechanical.

What no scan can do is generate field data for you. That comes from real visitors over 28 days and there is no way to shortcut it. If your site is new or quiet you will be working from lab measurements alone, and you should know that is what you are doing rather than assuming the numbers are what Google sees.

A scan also cannot tell you whether a page is worth making faster. That is a judgement about your business rather than a measurement.

The checks behind this guide

• Main content appears quickly on a phoneThe largest thing on the page — usually the main image or headline — is what a visitor is waiting for. Until it finishes loading they are looking at a blank or half-built page. This is measured on a mid-range phone on mobile data rather than on a fast desktop connection, because that is the harder case and the one most visitors are actually in.
• Page stays still while loadingContent moves after it first appears, so someone reading or reaching for a button can have it shift under them. This is what causes the mis-taps that make a site feel broken on a phone.
• Your site reacts quickly when real visitors tap itResponsiveness is how long a page takes to visibly react after somebody taps it — not how fast it loads, but whether it feels stuck once it has. It is the one thing a scan genuinely cannot measure, because there is nobody there to do the tapping, so a synthetic test can only estimate it from how busy the page looks. Where Google has collected the figure from real Chrome visitors, it is a measurement rather than an estimate, and it is usually caused by scripts doing work in response to the tap itself.
• Server responds promptlyThis is how long your hosting takes to begin sending the page at all — before any images, fonts or scripts have started. Every other speed improvement is stacked on top of this delay, so when it is slow it is the one to fix first.
• Main image is sized for the screenWhen the biggest image on the page is far wider than the space it is shown in, visitors download image data they can never see — and image data grows with the square of the width, so an image at twice the needed width is roughly four times the bytes. It is paid for on the connection least able to afford it.
• Images reserve their space before loadingThe browser cannot tell how tall these images will be until they have downloaded, so it draws the page without them and then pushes everything down when they arrive. That is the jump people experience as a page moving under their thumb.
• Google has enough visitor data to report on your siteGoogle publishes real-visitor speed figures for a site only once enough Chrome users have been there to make the numbers meaningful and anonymous. Below that threshold there is nothing to publish, which is the ordinary situation for a small business site and says nothing about how well the site is built. It does mean every speed figure in a report like this one is a simulation rather than a record of what happened to anybody.
• Other companies' code is a small share of your pageAnalytics, chat widgets, advert tags, embedded video players and social buttons all download code from somebody else's servers before your page is finished. Each one arrived for a reason, but they accumulate — nobody ever removes a tag — and they are downloaded over the visitor's connection, not yours. This is one of the few speed problems where the fix is a decision rather than a development project: something on the list is usually a tool the site stopped using and nobody switched off.