What Are Core Web Vitals and Why Do They Matter?

What Core Web Vitals are

Core Web Vitals are a small set of measurements Google uses to describe how a web page feels to a real person using it. Instead of vague talk about a site being "fast" or "slow," they put numbers on three specific experiences: how quickly the main content shows up, how quickly the page reacts when you tap or click, and how much the layout jumps around while it loads. Get those three right and a page tends to feel quick and steady. Get them wrong and it feels sluggish, jumpy, or frustrating, even if the visitor cannot say exactly why.

The reason these particular measurements exist is that Google wanted a shared, honest language for page experience. Before Core Web Vitals, everyone measured speed differently, and a lot of those numbers had little to do with what a human actually felt. Google narrowed it down to three things that map closely to real frustration, gave each one a clear name and a clear target, and started reporting them the same way across its own tools. That consistency is the point. When your developer, your marketer, and Google are all looking at the same three numbers, conversations about performance stop being arguments about opinion.

The three metrics are Largest Contentful Paint, which is about loading; Interaction to Next Paint, which is about responsiveness; and Cumulative Layout Shift, which is about visual stability. You will see them shortened to LCP, INP, and CLS almost everywhere, and we will use those short names throughout this guide. Each one answers a plain human question. Did the page show me something useful quickly? Did it react when I touched it? Did it hold still while I read it? A page that answers yes to all three feels good to use, and that good feeling is what Core Web Vitals try to capture in numbers.

It helps to be clear about what Core Web Vitals are not. They are not a full picture of quality. A page can pass all three and still be ugly, confusing, or useless. They do not measure whether your content is any good or whether your offer is compelling. They are a floor, not a ceiling: they tell you the experience is not actively getting in the way, which is a necessary starting point rather than the finish line. Think of them like the ride quality of a car. Smooth handling does not make it the right car for you, but a car that shudders and lurches is one you will not want to drive twice.

Why Google cares about them

Google sits on top of a promise: type a question, get a useful page. If the pages it sends people to are painful to use, that promise weakens. So Google has a direct interest in steering searchers toward sites that feel good, not just sites that happen to contain the right words. Core Web Vitals are part of how it measures the "feel good" side of that promise at scale, across billions of pages, without a human ever visiting them.

These three metrics live inside a broader idea Google calls page experience, which also includes things like whether a page works well on phones and whether it is served securely over HTTPS. Google has been public that page experience is one of many signals it uses to rank pages, and Core Web Vitals are the measurable heart of it. You can read Google's own framing of the metrics on web.dev, which is the closest thing to a primary source on what counts and why.

Here is the part where honesty matters, because plenty of articles oversell this. Core Web Vitals are a ranking signal, but they are not the ranking signal. Relevance and content quality still do the heavy lifting. A page with the best LCP on the internet will not outrank a genuinely better answer that happens to load a little slower. What Core Web Vitals more realistically act as is a tie-breaker and a floor. When two pages are similarly useful, the one that feels better to use has an edge. And a page with genuinely poor vitals can be held back, because a bad experience works against everything else you are trying to do. So the sensible way to treat them is not "fix these and rankings soar," but "fix these so a bad experience is not quietly costing you."

There is a second reason Google cares that has nothing to do with search rankings, and it may matter to your business even more. The same things that make Google happy make your visitors happy. Fast loading, quick response, and a stable layout are not abstract engineering goals. They are the difference between a visitor who sticks around and one who bounces before your page even finishes drawing. Google is, in a roundabout way, telling you what its enormous pile of data says about what keeps people on a page. That is worth listening to whether or not you care about search at all.

The three metrics in plain English

Let us walk through each metric the way you would explain it to a friend who does not build websites, because the plain-English version is the one that actually helps you make decisions.

Largest Contentful Paint (LCP): loading

LCP answers the question, "How long until the main thing on this page shows up?" Not the first pixel, not the loading spinner, but the largest, most meaningful piece of content in the first screenful, usually a big hero image, a video poster, or a large block of headline text. That is the moment a visitor feels the page has actually arrived and given them something to look at. A fast LCP means the page feels present quickly. A slow LCP means people stare at a mostly blank screen wondering if anything is happening.

Interaction to Next Paint (INP): responsiveness

INP answers, "When I tap or click something, how long before the page visibly reacts?" It watches the interactions a visitor makes across the whole time they are on the page, taps, clicks, key presses, and reports how quickly the page painted a response. A snappy INP means buttons feel alive and typing keeps up with your fingers. A poor INP means you tap a menu and nothing happens for a beat, so you tap again, and then two menus open. That laggy feeling is exactly what INP is built to catch.

INP is the newest of the three, and it replaced an older metric called First Input Delay, or FID, in early 2024. FID only measured the delay on the very first interaction, and only part of that delay at that. INP is stricter and fairer: it looks at interactions throughout the visit and measures the full time until you see a response, so it reflects real responsiveness far better than FID did. If you have older notes or articles that mention FID, mentally swap in INP, because FID is retired.

Cumulative Layout Shift (CLS): visual stability

CLS answers, "Does the page hold still, or does stuff jump around while it loads?" You have felt bad CLS many times. You go to tap a link, an ad or image finishes loading above it, everything shoves down, and your tap lands on the wrong thing. CLS is a score of how much unexpected movement happens as the page settles. A low score means the layout is calm and trustworthy. A high score means the page is playing a shell game with your fingers. Unlike the other two, CLS is a unitless score rather than a time, which throws people off at first, so we come back to what the numbers mean below.

The thresholds you have to hit

Each metric has three bands: good, needs improvement, and poor. Google publishes these cut-off points, so they are not something a consultant invents. Your goal is simple to state: land every metric in the good band. Here they are in one place.

Two details make these thresholds work the way they really work, and skipping them leads to confusion later. The first is that the assessment uses the 75th percentile of page loads. That means Google does not care about your best visit or your average visit. It looks at the experience of the slower quarter of your visitors and asks whether even they are getting a good result. Put plainly, seventy-five percent of your visits have to hit the good band for the metric to count as good. This is deliberately demanding, because it stops a site from hiding a bad experience for many people behind a great experience for a lucky few.

The second detail is that a page is only considered to pass Core Web Vitals overall when all three metrics are in the good band at that 75th percentile. You do not get a passing grade for nailing two and fumbling the third. That is worth remembering when you are tempted to pour all your effort into loading speed and ignore the jumpy layout. The three are graded together, so a single weak metric fails the whole page.

LCP: how fast the main content loads

LCP measures the render time of the largest content element visible in the initial view. In practice that is usually one of a few things: a large hero image, a background image, a video's poster frame, or a big chunk of text like a headline. The browser watches what gets drawn, decides which element is the largest meaningful one, and records when it appeared. The good target is 2.5 seconds or less at the 75th percentile.

Why 2.5 seconds and not something snappier? Because it reflects the point at which most people stop feeling like they are waiting and start feeling like the page has arrived. Beyond four seconds, patience runs out fast and people leave. The band between 2.5 and 4 seconds is the uncomfortable middle where the page works but feels heavy.

The thing to understand about LCP is that it is a chain, and the chain is only as fast as its slowest link. First your server has to respond to the request. Then the browser has to download and read the HTML. Then it often has to fetch and process CSS and JavaScript before it can even start drawing. Then it has to load the actual image or render the text. A delay anywhere along that chain pushes LCP later. That is why fixing LCP is rarely about one magic setting and more about finding which link in your particular chain is dragging. We get into the specific fixes further down, but the mental model to hold is a relay race: your LCP is the finish time, and any slow runner ruins it.

INP: how quickly the page responds

INP measures the time from a user interaction to the next frame the browser paints in response. When you click a button, the browser has to run whatever JavaScript that click triggers, then update the screen. If the main thread, the single lane where the browser runs your page's JavaScript, is busy doing something else, your click has to wait in line. INP captures that whole wait, across all the interactions during a visit, and reports a value that represents the slower interactions rather than the best case. The good target is 200 milliseconds or less at the 75th percentile.

The reason INP is such a useful metric is that it exposes a very common modern problem: sites that look loaded but are secretly frozen. A page can finish drawing, look completely ready, and then ignore your taps for half a second because it is still busy running scripts. LCP would not catch that, because the content is already there. INP catches it, because it is watching what happens when you actually try to use the thing.

Almost every INP problem traces back to JavaScript hogging the main thread. Too much of it, or a few tasks that run too long without pausing, and the browser cannot respond to input promptly. This is why heavy sites with lots of third-party scripts, analytics, chat widgets, ad code, tag managers, so often feel laggy on interaction. Each script is fighting for the same single lane your visitor's clicks need to travel down. The fixes, which we cover below, are mostly about doing less work on that main thread and breaking up the work you cannot avoid.

CLS: how stable the layout stays

CLS measures unexpected layout movement. Every time something on the page shifts position without the user causing it, the browser scores how much of the screen moved and how far. It adds those shifts up over the life of the page and reports a single number. Because it is a ratio of movement rather than a measure of time, it has no seconds or milliseconds attached. The good target is 0.1 or less, needs improvement runs to 0.25, and anything above 0.25 is poor.

The word "unexpected" is doing important work in that definition. If a visitor taps a button and a menu expands, that movement is expected and does not count against you. CLS only cares about movement the visitor did not ask for, the kind that makes them lose their place or tap the wrong thing. That distinction is why the fix for CLS is almost always about reserving space in advance, so that when something loads in, it slots into a spot that was already being held for it rather than shoving its neighbors aside.

The usual culprits are predictable once you know to look. Images and videos without dimensions set, so the browser does not know how tall they will be until they arrive. Ads and embeds that drop in and push content down. Banners injected at the top of the page after everything else has rendered. And web fonts that swap in and change the size of text, nudging the layout as they do. None of these are hard to fix, but they are easy to overlook, because on a fast developer machine with a warm cache the shifts barely show. On a real phone over a real network, they are jarring.

How the metrics are measured

Here is where a lot of confusion lives, and clearing it up will save you hours of frustration. There are two fundamentally different ways to measure Core Web Vitals, and they often disagree. Understanding why they disagree is the difference between chasing your tail and fixing the right thing.

Field data, the real story

Field data, also called real user monitoring, comes from actual visitors on actual devices and networks. Chrome quietly collects these measurements from real Chrome users who have opted in, and pools them into a public dataset called the Chrome User Experience Report, or CrUX. This is the data Google actually uses to assess your Core Web Vitals for ranking. It reflects your whole audience: the person on a top-end phone with fast fibre, and the person on a three-year-old handset with a weak signal on a train. That range is the point, and it is why the 75th percentile matters so much, because field data is where the slower quarter of your visitors shows up.

Lab data, the controlled test

Lab data comes from a tool loading your page in a controlled, simulated environment: one device profile, one network speed, one clean run. Lighthouse, the engine inside many testing tools, produces lab data. Its great strength is that it is repeatable and immediate. You change something, you rerun the test, you see the effect right away, without waiting weeks for real visitors to accumulate. Its weakness is that it is one simulated visit, not your real audience, so it is a diagnostic tool rather than the score of record.

Why the two disagree

They disagree constantly, and both are telling the truth. Lab data cannot measure INP well at all, because INP depends on real people interacting in ways a scripted test does not reproduce, so tools report a lab proxy instead of a real INP. Field data is an average of many varied visits over time, so it lags behind your latest changes and blends fast and slow conditions together. A page can look great in the lab and still fail in the field because your real visitors are on slower devices than the test assumed. The healthy way to use them together is this: treat field data as the truth about where you stand, and use lab data as the fast feedback loop while you experiment. Fix in the lab, confirm in the field.

Tools that report Core Web Vitals

You do not need to build anything to see your numbers. A handful of free tools cover both the field and lab sides, and knowing what each one is good for saves you from misreading them.

PageSpeed Insights

PageSpeed Insights is the friendliest starting point. You paste a URL and it shows you both sides at once: field data from CrUX at the top if Google has enough real-visitor data for that page, and a Lighthouse lab run below with specific suggestions. It is the single most useful tool for a business owner, because it puts the real-world verdict and the actionable fixes on the same screen. If the field section says "not enough data," it means your page has too little Chrome traffic to report, which is common for newer or lower-traffic pages.

Search Console Core Web Vitals report

Google Search Console has a dedicated Core Web Vitals report that groups all the pages on your site by status, good, needs improvement, or poor, using field data. This is the tool for seeing the whole site at once rather than one page at a time. It clusters similar pages together, so you can spot that, say, all your product pages share the same CLS problem and fix it once. If you care about search, this is the report to watch over time.

Lighthouse and Chrome DevTools

Lighthouse is built right into Chrome's developer tools, so your developer can run a lab audit on any page in seconds and get a prioritized list of issues. The developer tooling also lets you record a page load and see exactly which element counted as your LCP and which shifts hurt your CLS. This is where the actual debugging happens. Chrome's own documentation at developer.chrome.com goes deep on these tools if your team wants the full detail.

The web-vitals library and field monitoring

For a business that wants its own ongoing field data rather than relying on the pooled CrUX numbers, Google publishes a small open-source script called the web-vitals library that measures LCP, INP, and CLS from your real visitors and sends the results wherever you want them. Paired with your analytics, it gives you a live read on your own audience without waiting for the public dataset to update. It is a developer job to wire up, but it is not a big one. The technical details of how these metrics are defined live on developer.mozilla.org if you want a neutral reference outside of Google.

How to improve LCP

Because LCP is that relay race we described, improving it means finding and fixing the slow leg. Here are the usual wins, roughly in the order they tend to matter.

Speed up the server response

Nothing can render until your server answers, so a slow first response poisons everything downstream. Good hosting, caching so repeat requests do not rebuild the page from scratch, and a content delivery network that serves your files from a location near the visitor all cut this time. If you are on cheap, overloaded shared hosting, this is often the single biggest lever, and it is one many businesses overlook because hosting feels like a boring commodity. It is not. Our guide on how to improve your website speed digs into the hosting and caching side in more depth.

Remove render-blocking resources

Browsers often pause drawing the page while they download and process CSS and JavaScript in the head of the document. Trimming that blocking code, loading non-essential scripts later, and inlining just the small amount of CSS needed for the first screenful all let the browser start painting sooner. This is technical work, but it is some of the highest-value technical work there is for LCP.

Optimize the LCP image

If your largest element is an image, its size and format matter enormously. Serve modern formats, compress sensibly, and deliver an appropriately sized version rather than a huge original scaled down in the browser. A hero image that weighs several megabytes is a very common reason a page limps into the poor band.

Preload the LCP element

You can tell the browser to fetch the important hero image or font early, before it would otherwise get around to it, using a preload hint. That nudge moves your most important content to the front of the download queue instead of letting it wait behind less important files. Done for the right element, it can shave a meaningful chunk off LCP.

Prefer server rendering for content-heavy pages

If a page renders entirely in the browser, the visitor waits for JavaScript to run before they see the main content, which pushes LCP later. Rendering the important content on the server or building it ahead of time means the meaningful part arrives ready to view. This is one reason the choice of architecture matters so much, a theme we cover in static vs dynamic website.

How to improve INP

INP is almost always a JavaScript story, so improving it means being kinder to the main thread that handles both your scripts and your visitor's clicks.

Do less JavaScript work

The cheapest way to keep the main thread free is to give it less to do. Audit the scripts loading on your pages and cut what you do not need. Third-party tags accumulate quietly over the years, an old analytics tool nobody uses, three chat widgets from three experiments, a heavy carousel library for a carousel you removed. Every one of them competes for the lane your visitor's taps travel down. Trimming that pile is often the fastest INP improvement available.

Break up long tasks

When a piece of JavaScript runs for a long stretch without pausing, it blocks everything else, including responses to input. Splitting long tasks into smaller chunks, and yielding back to the browser between them, lets the browser slip in a response to a click rather than making it wait for the whole task to finish. This is a developer technique, but it is the core of most serious INP work.

Defer non-critical work

A lot of what a page does on load does not need to happen immediately. Loading things only when they are actually needed, and pushing non-urgent work to run after the page is interactive, keeps the early moments, when people are most likely to tap, clear for responding to them. Loading third-party scripts later rather than up front is a big part of this.

Debounce and throttle expensive handlers

If something runs on every keystroke or every pixel of scroll, it can flood the main thread. Debouncing, waiting until the activity settles before doing the expensive work, and throttling, limiting how often it can run, both keep those handlers from choking responsiveness. Search-as-you-type boxes and scroll effects are classic offenders that a little debouncing fixes.

How to improve CLS

CLS is the most fixable of the three, because the cause is nearly always the same: something loaded in without a space reserved for it. Reserve the space and the shift disappears.

Always set image and video dimensions

Give every image and video an explicit width and height, or the modern equivalent, so the browser knows how much room to hold before the file arrives. When the picture loads, it drops into the reserved slot instead of shoving everything below it down. This one habit prevents a large share of all CLS problems.

Reserve space for ads and embeds

Ads, social embeds, and iframes are notorious for appearing late and pushing content around. Set aside a fixed area for them ahead of time, matching the size they will be, so their arrival fills a waiting box rather than jolting the page. If you do not know the exact size, reserve a sensible minimum and accept a small placeholder over a big shift.

Do not insert content above existing content

Dropping a banner, a cookie notice, or a promo bar in at the very top of the page after everything below it has already rendered is a guaranteed shift, because it pushes the whole page down just as someone starts reading. Either reserve room for these from the start, or place them where they will not displace content people are already looking at.

Handle web fonts carefully

When a page first shows text in a fallback font and then swaps in your custom web font, the text can change size and reflow, nudging the layout. Loading fonts thoughtfully, and choosing fallback fonts that are close in size to the real ones, keeps that swap from causing a visible jump. This is a smaller effect than images or ads, but on a text-heavy page it adds up.

A practical checklist

If you want a plain, do-this list to work through with your team or hand to a developer, here it is. None of these require you to understand the code, only to make sure the work happens.

• Measure first. Run the page through PageSpeed Insights and note the field verdict for all three metrics before changing anything.
• Check the Search Console Core Web Vitals report to see which groups of pages are failing and which metric is the problem.
• For LCP: confirm your hosting is fast, caching is on, and a content delivery network is serving your files.
• For LCP: find your largest element and make sure, if it is an image, that it is compressed, correctly sized, in a modern format, and loaded early.
• For LCP: cut or defer render-blocking scripts and styles so the browser can start drawing sooner.
• For INP: audit every third-party script and remove anything you no longer use.
• For INP: ask your developer to break up long JavaScript tasks and defer non-critical work until after the page is interactive.
• For CLS: set width and height on every image and video across the site.
• For CLS: reserve fixed space for ads, embeds, and any banner that loads in late.
• For CLS: stop injecting content above what people are already reading.
• Retest in the lab after each change for fast feedback, then watch the field data over the following weeks to confirm real visitors saw the gain.
• Recheck after any big site change, because a new plugin, tag, or design tweak can quietly undo your work.

Common mistakes to avoid

The same errors trip up business after business. Knowing them ahead of time keeps you from wasting effort or, worse, breaking something while trying to fix it.

Chasing a perfect lab score and ignoring the field

It is easy to get hooked on making a lab tool show a big green number, but the lab is not what Google grades and not what your visitors live. A page can score beautifully in a single clean test and still fail in the field because real visitors are on slower devices. Watch the field data. That is the truth.

Treating Core Web Vitals as the whole of SEO

Fixing your vitals will not rescue thin content or vault you past genuinely better pages. They are a supporting signal and a floor, not a substitute for being the best answer. Spend accordingly: get the vitals into the good band so they are not hurting you, then put your real energy into content and relevance.

Fixing it once and forgetting it

Performance rots. Add a new marketing tag here, a heavier image there, a fresh plugin over there, and the numbers you worked hard for slide back into the amber. Core Web Vitals need occasional rechecking, especially after any noticeable change to the site, or they quietly decay.

Optimizing one metric and ignoring the other two

Because the page only passes when all three are good, pouring everything into LCP while CLS stays poor gets you nowhere on the overall grade. Look at all three together and fix whichever is weakest first, rather than polishing the one that was already fine.

Blaming the platform instead of the build

People love to say a certain platform is just slow. Usually the platform is fine and the specific build is heavy: too many scripts, unoptimized images, no caching. The same tools that let you build a bloated site let you build a fast one. If you are weighing platforms, our comparison of React vs WordPress gets into how build choices, not brand names, decide performance.

How they relate to SEO and sales

Let us tie this back to why you would spend the effort at all, because the honest business case is stronger than the hype and does not need exaggerating.

On the SEO side, treat Core Web Vitals as a real but modest factor. They are part of Google's page experience signals, and a page that passes has a small advantage over an equally relevant page that does not, while a page with genuinely poor vitals can be held back. What they will not do is outrank better content on their own. The right framing is defensive: get into the good band so that a bad experience is not quietly working against all the other, bigger things you do to rank. It is a floor you want to be standing on, not a rocket.

The conversion side is where the business case gets more direct, and it does not depend on Google at all. Every one of these metrics maps to a moment where you can lose a visitor. A slow LCP means people stare at a blank screen and some of them leave before your page even appears. A poor INP means the page feels broken when they try to use it, and a page that feels broken does not get trusted with a credit card. A high CLS means people tap the wrong thing, get annoyed, and sometimes buy the wrong thing or give up. None of that requires a study to believe, because you have felt all three yourself and you know what you did: you left. A faster, steadier, more responsive page keeps more of the people you already worked hard to attract, and keeping them is usually cheaper than finding new ones.

There is a compounding effect worth naming too. The work that improves Core Web Vitals, lighter pages, fewer scripts, better images, solid hosting, tends to improve the whole experience, not just the three measured numbers. A site built with performance in mind feels more professional, and that impression colors how people judge your business before they read a word. If you are building something more involved than a simple site, our explainers on what is a web application and what is a progressive web app show how these same performance habits carry into more ambitious projects. And if you want the whole thing handled properly rather than piecemeal, our services cover performance work as part of building and maintaining a site that holds up.

Final thoughts

Core Web Vitals are Google's attempt to put honest numbers on three things every visitor feels: does the main content show up quickly, does the page respond when I touch it, and does the layout hold still while I read. LCP, INP, and CLS each have a published good target, 2.5 seconds, 200 milliseconds, and 0.1, measured at the 75th percentile of real visits, and a page passes only when all three land in the good band. That is the whole framework, and once you see it that way it stops feeling mysterious.

The practical path is not complicated. Measure with the real tools, find which of the three is weakest, fix the specific cause, and confirm the gain in field data rather than trusting a single lab run. Keep an eye on it over time, because performance drifts as sites grow. And keep the metrics in proportion: they are a floor that keeps a bad experience from costing you, not a magic ranking button, and the bigger prize is the visitors you keep because the page simply feels good to use.

If reading all this has confirmed that your site has a problem you would rather not untangle yourself, that is a normal place to land, and it is exactly the kind of work we do every week. Send us your site, tell us what feels slow or jumpy, and we will give you a straight read on where you stand and what is worth fixing first. You can request a free quote whenever you are ready, and we will help you get all three numbers into the green without the guesswork.