Core Web Vitals: measure and improve them

What Core Web Vitals are

Core Web Vitals are three numbers Google uses to describe how a page feels to a real visitor. Does the main content appear quickly? Does the page react when you tap it? Does it stay still while it loads, or jump around? Each question has one number, and each number has a limit Google calls good.

Google says these numbers are used by its ranking systems, as part of page experience. It also says a good page experience does not make up for weak content. Think of them this way: they rarely lift a page on their own, but a slow, jumpy page loses visitors whatever its position. Fixing them is worth it for the people on the page.

The three numbers in plain words

LCP: Largest Contentful Paint

The time until the biggest picture or block of text in the visible part of the page has appeared. On most pages that is the main photo or the headline. Good is 2.5 seconds or less. Seoga’s scan reports a slow one as “The main part of your page loads slowly”.

INP: Interaction to Next Paint

How long the page takes to show a response after a tap, click or key press, judged over the whole visit. Good is 200 milliseconds or less. In 2024 it replaced an older measure, First Input Delay, which only looked at the first tap. In a Seoga scan: “Your page reacts slowly when tapped”.

CLS: Cumulative Layout Shift

How much the content moves around unexpectedly while you look at it. It has no unit; good is 0.1 or less. You have felt it when a button moves just as you tap it, because a banner loaded above it. In a Seoga scan: “Your page jumps around while loading”.

Real visitors versus a lab test

There are two kinds of figures, and mixing them up causes most of the confusion around speed.

• Field data comes from real Chrome users who visited your pages, collected in the Chrome UX Report over the last 28 days. This is what Google uses. It only exists once a page or site has enough visits; a new or quiet site may have none, which Seoga’s scan shows as “Google has no real-visitor speed data for your site yet”.
• Lab data comes from one test run on a simulated device, such as Lighthouse. It is available for any page, any time, and is good for finding causes. It can’t measure INP, because nobody taps the page in a lab; Total Blocking Time is the lab figure that points the same way.

When the two disagree, trust the field data for the verdict and use the lab test to find out why.

Where to find your figures

1. Start with Search Console. Open Experience, then Core Web Vitals. It groups your pages into good, needs improvement and poor, separately for phones and computers, using field data. Click a problem to see example pages.
2. Test one page in PageSpeed Insights. Enter the address at pagespeed.web.dev. The top part shows field data for that page or the whole site when Google has it; the lower part is a Lighthouse lab test with a list of what slows the page down.
3. Look at phones first. Google ranks the phone version of pages, and phones are where pages are slowest. Fix the phone figures first.
4. Fix templates, not single pages. Pages built from the same layout usually share the same problems. Search Console groups similar pages for this reason.

Which pages to fix first

You will rarely fix all three numbers on every page at once, and you don’t need to. Start where visitors and money are. Use your analytics or the Performance report in Search Console to list the pages with the most visits from search, then check their Core Web Vitals. A product template used by hundreds of pages, or the home page, is worth more attention than a rarely visited article.

Then pick the number that is furthest from good. A page with an LCP of 6 seconds and a CLS of 0.12 has one urgent problem and one small one. Work on the loading first; the small shift can wait for the next round. After each change, test the page again in the lab so you know the change helped before moving on.

How to improve LCP

• Make the main picture smaller. Resize it to the size it is shown at, and use a modern format such as WebP or AVIF. In a scan: “Your page’s images are too heavy”.
• Load the main picture first. Don’t lazy-load the picture at the top of the page. You can mark it with fetchpriority="high" so the browser fetches it early.
• Answer faster from the server. If the first byte takes over about 0.8 seconds, everything else waits. Caching and a content delivery network help: “Your server is slow to start answering”.
• Clear the way. Styles and scripts loaded at the top can hold back the whole page: “Scripts block your page from showing”.

How to improve INP

• Load less JavaScript. Remove plugins and scripts you don’t use. Every script a phone has to run makes taps wait: “Your page loads too much JavaScript”.
• Break up long tasks. Code that runs for more than 50 milliseconds at a time blocks the page. Developers can split it into smaller pieces or move it off the main thread.
• Delay other companies’ code. Chat widgets, trackers and ad scripts often cause slow taps. Load them after the page is ready, or only when they are needed: “Outside scripts slow your page down”.

How to improve CLS

• Give pictures and videos a size. Set width and height on every image so the browser keeps space for it: “Your images have no fixed size”.
• Keep space for late content. Banners, cookie notices and ads should have a reserved space, or appear over the page rather than pushing it down.
• Load fonts calmly. A web font that arrives late can reflow the text. Preloading the main font and using a matched fallback reduces the jump.