What Are Core Web Vitals? Understanding LCP, INP and CLS

Core Web Vitals are three metrics Google uses to measure how a web page feels to users: how quickly the main content appears (LCP), how quickly the page responds to taps and clicks (INP), and how much the content jumps around while loading (CLS). All three are measured with data from real visitors and show up in Search Console as your site's report card.

It sounds technical, but each one maps to an annoying moment we all know. A page sitting on a blank white screen, a button that does nothing when you press it, a link that slides down just as you are about to tap it. Below we explain each one starting from those everyday moments.

LCP: how fast does the main content appear?

LCP (Largest Contentful Paint) is the moment the largest image or text block on the page appears on screen. On most sites that is the big photo at the top or the main heading. Think of sitting down in a restaurant: the waiter bringing water is a good sign, but what you care about is the main course reaching the table. LCP is the time it takes for the main course to arrive.

By Google's published standard, an LCP of 2.5 seconds or less is good and more than 4 seconds is poor. In between is 'needs improvement'.

On small business sites, the cause of a bad LCP is often the same: a photo of several MB taken on a phone and uploaded as-is to the top of the homepage. On desktop with fast internet you don't notice; on mobile over a weak connection it can take seconds. Resizing that image properly and converting it to a modern format like WebP or AVIF often improves LCP noticeably. Other common causes are a slow server and heavy font and script files loaded at the top that delay the page from appearing.

Then there is the slider. Five big rotating photos at the top of the homepage can delay LCP, and many visitors never look past the first slide. A single, well-chosen image is usually both faster and more effective.

INP: how quickly does the site respond?

INP (Interaction to Next Paint) measures how long it takes for the page to show a visible response after a visitor taps, clicks or presses a key. Think of a doorbell. You press it and hear nothing inside. You press again. Maybe the bell is broken, maybe nobody is home. The same thing happens on a site: someone taps the menu button, nothing happens, they tap again, and the menu opens and closes twice.

As Google announced, INP replaced the old FID metric in 2024. FID only measured the first interaction; INP reports a value close to the slowest interactions during the whole visit. Google's thresholds: 200 milliseconds or less is good, more than 500 milliseconds is poor.

What usually hurts INP is a busy browser. Lots of JavaScript running while the page loads, especially third-party scripts (live chat windows, ad and tracking codes, social media embeds, heavy cookie banners), keeps the browser busy, and the user's click has to wait in line. On any platform, a large number of plugins that each load their own script can have the same effect. The first step is to remove scripts the page doesn't actually use and make the rest load after the page appears.

CLS: why does the page jump?

CLS (Cumulative Layout Shift) measures unexpected movement of content while the page loads. Everyone has been there: you reach for a news link, an ad loads above it at that exact moment, everything shifts down and you tap something else. On an online store that means tapping a different product instead of 'add to cart'. On a form page, typing in the wrong field.

CLS is a score, not a time. By Google's standard, 0.1 or less is good, more than 0.25 is poor.

The most common cause is images without set dimensions. The browser doesn't know how much space the image will take, so it leaves no room for it, and when the image arrives it pushes everything below it down. Giving images width and height values, or fixing their aspect ratio in the code, solves this. Other causes are banners that load later, cookie notices, promo strips, and web fonts that arrive late and change the size of the text. Space for these elements needs to be reserved from the start.

Field data versus lab data

When you test your site in Google's PageSpeed Insights, you see two separate sections, and this is where clients get most confused.

The top section is field data. It is compiled from the experience of real visitors using Chrome over the past 28 days, and it is the data Google uses in its page experience assessment. The assessment is based on what 75 percent of visits experience: if three quarters of visitors have a good experience, the metric counts as good. If your site is new or gets few visitors, this section may be empty because there isn't enough data.

The bottom section is lab data. It is a single test run on Google's servers at that moment, simulating a throttled mobile connection and a mid-range phone. The score (the coloured circle from 0 to 100) comes from here. It is very useful for diagnosing problems, but it gives slightly different results each time and doesn't feed directly into ranking.

So the answer to 'my PageSpeed score is 62, is that bad?' is usually 'let's look at the field data'. A site with a lab score of 62 but all three metrics green for real users is in good shape as far as Core Web Vitals go. The opposite can happen too.

How much does it affect rankings?

Google openly says it uses Core Web Vitals as one of its ranking signals. It also says that a good page experience doesn't outrank relevant, high-quality content. In practice we read it like this: between two pages that cover the searched topic well, the fast and smooth one may get a step ahead. But a fast page that doesn't answer the question can't beat a slower page that does.

Still, treating Core Web Vitals as purely an SEO issue misses the point. On a page that is slow to open on mobile, many visitors leave before it loads. On a page you are paying to advertise, that means wasted clicks. Speed affects conversion before it affects ranking.

The most practical place to start is the Core Web Vitals report in Search Console, which shows which metric is a problem on which group of pages. Then open those pages one by one in PageSpeed Insights and look at the suggestions; that tells you where to begin. We explained how to fix issues in order of the most gain for the least effort in our article on speeding up slow sites, and covered mobile-friendliness testing in a separate one.