Core Web Vitals, explained for business owners

If your website feels slow, your visitors notice before you do. Google noticed too, and since 2021 it has used a set of measurements called Core Web Vitals as part of how it evaluates pages. You do not need to be a developer to understand them, and knowing what they mean will help you ask the right questions of whoever builds your site.

What Google actually measures

Core Web Vitals are collected from real visitors using Chrome, not from a lab test. That matters: the numbers reflect your actual customers, on their actual phones and networks. There are three of them.

1. Largest Contentful Paint (LCP): how fast it looks ready

LCP measures how long it takes for the biggest thing on the screen, usually a headline or a hero image, to appear. It is the moment a visitor feels "the page has loaded".

Google's target is 2.5 seconds or less for most visits.

2. Interaction to Next Paint (INP): how fast it responds

INP measures how quickly the page reacts when someone taps a button, opens a menu or types in a form. A page can look loaded and still feel frozen if the browser is busy running code.

Google's target is 200 milliseconds or less.

3. Cumulative Layout Shift (CLS): how stable it is

CLS measures how much the page jumps around while it loads. You have felt this: you go to tap a link, an image loads above it, and you tap an advert instead.

Google's target is a score of 0.1 or less.

You can read Google's own definitions on web.dev.

Why this matters to your business

There are two reasons, and the second is the bigger one.

Search. Page experience is one of many signals Google uses. Good Core Web Vitals will not rescue a page with poor content, but between two similarly useful pages, the faster and more stable one has an edge.

People. Slow, jumpy pages lose visitors before they ever read your offer. Every second a phone user stares at a blank screen is a second they might hit the back button. Fixing performance is one of the few improvements that helps every visitor at once.

What usually causes poor scores

In our experience, most problems come from a short list:

• Heavy images uploaded straight from a camera or design tool, many times larger than needed.
• Too much JavaScript, often from themes, page builders, chat widgets and tracking scripts that each seemed harmless on their own.
• Fonts and images without reserved space, which push content around as they load.
• Slow servers or no caching, so every visit waits for the page to be built from scratch.

What fixes them

The good news is that the fixes are well understood:

1. Serve modern, right-sized images. Formats like AVIF and WebP, sized for the screen that shows them, are often a fraction of the original file.
2. Send less code. Remove scripts you do not need, and load the rest only when they are used. A chat widget can wait until someone clicks "chat".
3. Reserve space for everything. Give images and embeds fixed dimensions so nothing jumps.
4. Render pages on the server and cache them. Visitors then receive ready-made HTML instead of waiting for it to be assembled in their browser.

How to check your own site

Open PageSpeed Insights, paste your address and look at the section labelled with real-user data. If it shows "Passed" for Core Web Vitals, you are in good shape. If not, the report lists what is holding each number back.

Treat the lab score underneath as a guide rather than a grade: it simulates one slow phone, while the real-user data reflects your actual audience.

The short version

Fast, stable pages are good for search and better for people. The three numbers to watch are LCP (looks ready), INP (responds quickly) and CLS (does not jump). Most problems come from heavy images and too much code, and most fixes come from sending less of both.

If you would like us to look at your site, book a call and we will walk you through what we find.