Core Web Vitals Explained for Business Owners

Core Web Vitals are a set of measurements Google uses to judge how a page feels to real visitors: how quickly it loads, how quickly it responds and how stable it is while loading. They sound technical, and the fixes often are, but the ideas behind them are simple. This guide explains them in plain English so you can have a useful conversation with your developer or agency.

Why Core Web Vitals matter

Google uses Core Web Vitals as part of its page experience signals. They are not the most important ranking factor. Relevant, helpful content still matters far more, and a fast page with weak content will not outrank a slower page that answers the question better.

The bigger reason to care is your visitors. Slow, jumpy or unresponsive pages frustrate people, and frustrated people leave. Improving these measures often improves the experience for everyone, which can support enquiries and sales as well as search.

The three Core Web Vitals

Largest Contentful Paint (LCP): loading

LCP measures how long it takes for the largest visible element on the screen, usually a main image, a video poster or a large block of text, to appear. It reflects the moment a visitor feels the page has actually loaded.

Good: 2.5 seconds or less.

Common causes of slow LCP include large uncompressed hero images, slow server response times, heavy themes and too many scripts and stylesheets loading before the main content.

Interaction to Next Paint (INP): responsiveness

INP measures how quickly a page responds visually when someone interacts with it, for example tapping a button, opening a menu or typing in a form. It looks across the interactions during a visit and reports a value that represents the slower ones.

Good: 200 milliseconds or less.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was handled, while INP looks at responsiveness throughout the visit, which is a fuller picture of how a page feels to use.

Poor INP is usually caused by heavy JavaScript keeping the browser busy. Third-party scripts such as chat widgets, tracking tags and advertising code are frequent culprits.

Cumulative Layout Shift (CLS): visual stability

CLS measures how much the page layout moves around unexpectedly while it loads. You have probably experienced it: you go to tap a link and the page jumps because an image or banner loaded above it.

Good: 0.1 or less. CLS is a score, not a time.

Typical causes include images and videos without set dimensions, adverts and embeds that load late, cookie banners pushing content down and web fonts that change the size of text after it appears.

Field data versus lab data

You will see two kinds of Core Web Vitals data, and it helps to know the difference.

Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report. This is what Google uses for its assessment. It is based on the 75th percentile of visits, so most of your visitors need a good experience, not just those on fast connections.
Lab data comes from a simulated test on a single device and connection. It is useful for diagnosing problems and testing fixes, but it may not match what real visitors experience.

Smaller sites may not have enough traffic for field data on every page. In that case, lab tests and grouped data for similar pages give you something to work with.

How to check your site

Google Search Console. The Core Web Vitals report groups your URLs into “Good”, “Needs improvement” and “Poor” for mobile and desktop, using field data.
PageSpeed Insights. Enter a URL to see field data where available, plus a lab test with specific suggestions.
Chrome DevTools and Lighthouse. Useful for developers who need to dig into exactly what is slowing a page down.

Start with mobile. It is usually where the problems are greatest and it is the version Google primarily uses.

Fixes that often help

For LCP

Compress and correctly size the main image, and serve it in a modern format such as WebP or AVIF.
Do not lazy load the main image at the top of the page.
Improve server response time with better hosting, caching and a content delivery network.
Remove or defer scripts and styles the page does not need straight away.

For INP

Audit third-party scripts and remove those you no longer use.
Load non-essential scripts later or only when needed.
Ask your developer to break up long JavaScript tasks so the browser can respond between them.
Be cautious with heavy page builders and plugins that add large amounts of code to every page.

For CLS

Set width and height on images, videos and embeds so the browser reserves space for them.
Reserve fixed space for adverts, banners and widgets that load late.
Avoid inserting content above existing content unless the visitor asked for it.
Load web fonts in a way that minimises visible shifts in text size.

Keep expectations realistic

Improvements in field data take time to show, because the data covers a rolling 28-day period of real visits. Fix the biggest problems first, confirm them with lab tests, then give the field data several weeks to catch up. It is also normal for a site redesign, a new plugin or a new marketing tag to undo earlier gains, so check the report regularly.

Key takeaways

LCP measures loading (aim for 2.5 seconds or less), INP measures responsiveness (200 milliseconds or less) and CLS measures stability (0.1 or less).
INP replaced FID in March 2024 and gives a fuller view of how responsive a page feels.
Google assesses real-user field data, so focus on the experience of typical mobile visitors.
Images, hosting, third-party scripts and missing dimensions cause many common problems.
Core Web Vitals support good SEO, but they do not replace helpful content.

If your pages are struggling with any of these measures, SEO Fleet’s website speed optimisation service can identify the causes and fix them, and our technical SEO team can check that speed improvements sit alongside a healthy, crawlable site.