Core Web Vitals explained: how to read your report

Open Google Search Console for most small business websites and you’ll find a Core Web Vitals report with some red and amber in it. Run the same site through PageSpeed Insights and you get a score out of 100, plus a list of suggestions written for developers. Neither report explains itself very well. Both look like they were designed to make you call a developer.

This guide explains what those reports are telling you in plain English. It covers why the numbers sometimes disagree, and which kinds of fixes move which measure.

What are Core Web Vitals?

Core Web Vitals are 3 measurements Google uses to describe how a page feels to use. Largest Contentful Paint (LCP) checks how fast the main content appears. Interaction to Next Paint (INP) checks how fast the page responds to a tap. Cumulative Layout Shift (CLS) checks whether the page jumps around.

Each one answers a simple question.

Largest Contentful Paint (LCP): how long until the main thing appears? It measures the time from when someone starts loading the page to when the largest visible element has rendered. That element is usually the hero image or the main heading. A good LCP is 2.5 seconds or less.

Interaction to Next Paint (INP): how quickly does the page respond? When someone taps a button, opens a menu or types in a field, INP measures how long until the screen visibly responds. It replaced an older measure called First Input Delay in March 2024. INP is stricter, because it looks at interactions across the whole visit rather than just the first one. A good INP is 200 milliseconds or less.

Cumulative Layout Shift (CLS): does the page jump around? It scores how much visible content moves unexpectedly while the page loads. Think of text shoving down when an image or banner appears above it. A good CLS is 0.1 or less.

A page passes Core Web Vitals when all 3 are in the good range.

Why do field data and lab data disagree?

Field data comes from actual Chrome users visiting your site over the last 28 days. Lab data comes from a single simulated test on a mid-range phone. Your visitors may have faster or slower phones and connections than the test. So the 2 numbers often differ, and both can be correct.

This is where most confusion comes from.

Field data is measured from live visitors using Chrome, collected into what Google calls the Chrome User Experience Report. Search Console’s Core Web Vitals report uses field data. So does the top section of PageSpeed Insights, labelled as real user experience. It reflects your actual audience, on their own phones and connections, over the previous 28 days. Google assesses each measure at the 75th percentile. That means 3 in 4 visits need to be in the good range for the page to pass.

Lab data is a single simulated test run in controlled conditions. It typically imitates a mid-range phone on a slowish mobile connection. The Performance score out of 100 in PageSpeed Insights and Lighthouse is lab data.

They disagree for good reasons. Your visitors might be mostly on fast office connections, so field data looks better than the lab. Or they might be on older phones in regional areas, so it looks worse. The lab also can’t measure INP directly, because nobody is tapping anything. It uses a stand-in measure instead.

The rule of thumb: field data tells you whether you have a problem; lab data helps you find out why.

Why does a smaller site show “not enough data”?

Field data only exists when enough Chrome users have visited a page. Smaller sites often see “not enough data” for individual pages, and Search Console groups similar pages together instead. That’s normal. In those cases, lab testing on your most important pages is the best guide you have.

What causes a slow LCP?

A slow LCP usually comes from the hero image. It may be too large, found late by the browser, or lazy loaded when it should load first. A slow server, heavy web fonts and scripts in the page head can also delay it. Fixing the hero image is often the biggest single win.

On most business websites, the largest element is an image. A slow LCP comes down to a few familiar causes:

• The hero image is too big. A photograph exported at several megabytes, in an older format, served at full size to a phone.
• The image is found late. A script or a CSS background loads it, so the browser doesn’t know about it until well into loading.
• The image is lazy loaded. Lazy loading is good for images further down the page. Applied to the hero, it delays the one image that matters most.
• The server is slow to respond. If the first byte of the page takes a second to arrive, everything else starts a second late.
• Fonts and scripts block rendering. Heavy web fonts and third-party scripts in the head of the page hold up the first paint.

The fixes are the reverse. Compress and resize images into modern formats. Load the hero image directly and with priority. Keep lazy loading for images below the fold. Use fast hosting with caching, and defer anything the first view doesn’t need. Our website speed optimisation work usually starts with exactly this list.

What causes a poor INP score?

A poor INP score comes from JavaScript doing too much work when someone interacts. Large script bundles, stacks of third-party tags, heavy page builders and filters that redraw the whole page are the usual causes. Removing scripts you no longer need is often the most effective fix.

Common culprits:

• Large bundles of script running on every page, including features the page doesn’t use.
• Third-party tags for chat, analytics, heatmaps and advertising, each adding work.
• Page builders and sliders that recalculate the layout on every tap.
• Menus and filters that re-render large parts of the page when a single option changes.

Fixes include removing scripts that are no longer needed and loading third-party tags later, or only where they’re used. Breaking long tasks into smaller ones helps too, as does building interactive parts to do less work. Often the single most effective step is an honest review of every tag on the site and what it’s for.

What causes layout shift?

CLS is often the easiest to fix once you see it:

• Images and videos without width and height set, so the browser doesn’t reserve space for them.
• Cookie banners, promotional bars and chat widgets that push content down after it has appeared.
• Web fonts that load late and change the size of text when they swap in.
• Ads and embeds that expand after loading.

Set dimensions on every image and reserve space for anything that loads late. Overlay banners rather than inserting them above content. And choose font loading settings that keep the swap small.

Do Core Web Vitals affect Google rankings?

Yes, a little. Google says page experience, including Core Web Vitals, is one of many ranking signals, and that relevant, helpful content matters more. A fast page with thin content won’t outrank a slower page that answers the question well. Speed matters more for visitors, who leave slow pages before reading anything.

Your visitors care about speed more than Google does. For a store, a booking site or any business where the website is the sales channel, that is lost revenue whether or not a ranking changes. Performance is part of the technical SEO foundation. It’s also simply part of a site that works.

How to read your own report in 5 minutes

1. Open Search Console and go to the Core Web Vitals report. Look at the mobile report first, because it’s almost always the harder one to pass.
2. Note which measure is failing and how many URLs are affected.
3. Click through to an example URL group and open one example page in PageSpeed Insights.
4. In PageSpeed Insights, read the real user section first to confirm the problem. Then read the diagnostics below it to see likely causes.
5. Fix the cause on the template, as well as the page, because pages in a group usually share one.

After a fix, remember field data is a 28-day rolling window. It takes several weeks for improvements to show fully in Search Console.

Where hosting fits

Some performance problems can’t be fixed in the page at all. Slow servers, no caching and no content delivery network put a ceiling on how fast any page can be. Good managed hosting removes that ceiling, and it’s often the cheapest improvement available.

Core Web Vitals reports look technical, but the questions behind them are human ones. Does the page show up quickly? Does it respond when I touch it? Does it stay still while I read it? A site that answers yes to all 3 is a better site, whatever the ranking does.

Want a site that passes before it launches?

Every site we build is tested for speed before release, and one recent launch scored 96 for Lighthouse performance and 100 for best practices. See how our website speed optimisation service works on an existing site. Book a free strategy call and we’ll tell you which of your 3 scores is costing you the most.