Web Performance Monitoring

Understanding Core Web Vitals & Why They Matter

By: August Flanagan|Last Updated: Oct 09, 2026

Have you ever noticed that some websites appear to load quickly, but then suddenly become unresponsive when you try to click on a button or image?

In the past, website owners relied on technical measurements such as the page load time to understand how fast a website loads on a visitor's device. Site speed is a useful metric to track, but page load time does not tell the full story when it comes to user experience. That's where Core Web Vitals come in.

In this guide, you'll learn what Core Web Vitals are, how they affect search ranking and user experience, and we'll cover some practical tips on how to easily measure these metrics. Thresholds are from web.dev's Web Vitals article.

What are Core Web Vitals

Web Vitals are a set of standardised metrics proposed by Google, that help understand how visitors are really experiencing a website, rather than relying on performance scores and artificial benchmarks.

Core Web Vitals are the three metrics Google asks every site to measure. Judge each one at the 75th percentile of page loads, with mobile and desktop counted separately:

  1. Largest Contentful Paint (LCP), how fast the main content on a website loads. Good is 2.5 seconds or less. Poor is more than 4 seconds.
  2. Interaction to Next Paint (INP), how long the page takes to respond to interactions across the visit. Good is 200 milliseconds or less. Poor is more than 500 milliseconds.
  3. Cumulative Layout Shift (CLS), how visually stable is the website layout as content loads. Good is 0.1 or less. Poor is more than 0.25.

The chart below is older than that list. It shows Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. First Input Delay was the interactivity metric until INP replaced it. web.dev's FID article says FID is no longer a Core Web Vital, and that support ended on 9 September 2024.

Threshold bars for Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift, with good, needs improvement, and poor ranges. Older target chart: LCP, FID, and CLS. Google's current three are LCP, INP, and CLS.

Largest Contentful Paint

Largest Contentful Paint (LCP) is a metric that measures how long it took for the main piece of content to load on the screen, as opposed to the time it took for the entire page to load.

Which component is the main piece of content highly depends on your website. Most tools that measure this metric will automatically identify the largest block of content presented on the website as it loads.

Things that might affect LCP include large images, video players, website backgrounds, large blocks of text, and other render blocking resources. Essentially, anything that might cover a large portion of the initial viewport.

How is it different from page load time?

It's different from the page load time, as it measures what the visitor perceives instead of the actual number on paper. For example, while a page might load in 5 seconds, the main piece of content, such as a big image, or block of text might have already loaded 2 seconds in. That means that the remaining 3 seconds are just spent on loading secondary content which does not prevent the visitor from already looking at the site. Page load time is still worth tracking. It answers a different question.

It's generally a good idea to keep LCP within 2.5 seconds to ensure your website feels fast, and visitors don't leave while waiting for something to appear on screen. An LCP of 4 seconds or more is considered to lead to a poor experience. The band between the two is "needs improvement." web.dev's LCP article is the long version.

Interaction to Next Paint

Interaction to Next Paint (INP) measures responsiveness across the visit. It looks at click, tap, and keyboard interactions. The value is the slowest of those interactions, ignoring one outlier for every 50 interactions when the page has that many. The visitor feels it as the wait between an action and the next paint.

INP replaced First Input Delay as a Core Web Vital in 2024. FID only timed the delay before the browser could start handling the first input. It ignored the rest of the handler and every later interaction. web.dev's INP article has the scoring bands: 200 milliseconds or less is good, up to 500 milliseconds needs improvement, and above 500 milliseconds is poor.

A standard Lighthouse navigation run loads the page with no user, so it does not record INP. Timespan mode can, if someone interacts during the recording. web.dev says to treat Total Blocking Time as the lab stand-in for a navigation run.

Cronitor's Performance chart does not include INP. The selector has Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. If you need the INP number Search Console publishes, use Search Console or the web-vitals library.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) measures the visual stability of a website. In other words, it measures by how much the main elements shift around as the page loads.

To understand it, you have to put yourself in the shoes of the visitor. It can be highly frustrating when a button or image moves around while you're trying to focus on it. Even worse when you end up clicking on something you didn't want because the content moved around as the page continued to load. That's why striving for visual stability as the page loads is important.

CLS can be affected by lazy loading images, delayed popups, banners, and wrongly-sized placeholder blocks or images. Essentially anything that can cause significant layout changes as a page loads.

Keeping your CLS score to a minimum can greatly improve your website's usability. Google recommends a CLS of 0.1 or less. Above 0.25 is poor. Details are on web.dev's CLS article.

First Input Delay

First Input Delay (FID) measures input delay. In other words, it measures how quickly a user can start interacting with a website, even if it's still loading. A page can look ready while the main thread is still busy parsing JavaScript. The first tap sits in a queue. That queue time, before the handler starts, is FID.

For example, maybe a page is still loading, but the visitor wants to click on a button or expand an image that is already visible on screen. There's no need to wait around in order to be able to perform an action. If the site immediately reacts to these interactions, it feels snappy and responsive.

Unlike LCP and CLS, FID is difficult to measure using "offline" tools. It requires actual user input. Field data tools perform continuous measurements on a website's live traffic, which is a closer picture of what visitors hit than a lab run with no one clicking.

Google's old guidance, still printed on the chart above, is a FID of 100 milliseconds or less. An input delay larger than 300 milliseconds can lead to a poor user experience. Cronitor still draws those lines on the First Input Delay view, as median, p95, and p99.

It may be tempting to try and reduce input delay to a minimum, but it's important to consider that there's a practical limit on how much better it can be. While most humans can notice the difference between 800 milliseconds and 100 milliseconds, a 10 millisecond difference might be just barely noticeable.

How to measure Core Web Vitals

Peter Drucker is often quoted as saying that "if you can't measure it, you can't improve it". The point being that you can't know with certainty whether something worked or not just by guessing. Without data, all we have are opinions, which may differ from the truth.

On that principle, the first step towards delivering a great experience on your website should be to start measuring the metrics that matter. That way you'll know where you stand, and whether any changes you perform have a positive effect on the end-user experience.

You can start by performing synthetic checks on your website using lab tools such as Lighthouse in order to understand the current state of your website.

Lighthouse example report Example lighthouse report.

Once you have identified existing issues, and possible improvements, you could add a monitoring solution, either lab-based (offline checks) or field-based (using real traffic), in order to continuously monitor the metrics that matter for you.

In Cronitor, open the site, then Performance, and choose Largest Contentful Paint, First Input Delay, or Cumulative Layout Shift on the chart. The shot below is Largest Contentful Paint, with Good at 2.5 seconds and Needs improvement at 4 seconds. Those lines match Google's LCP thresholds. The series are median, p95, and p99, which is not the 75th percentile Google scores.

Largest Contentful Paint on Cronitor's Performance chart, with median, p95, and p99, and Good and Needs improvement reference lines. Largest Contentful Paint on a Cronitor site.

In order to achieve the best results, most websites use a combination of tools as part of their monitoring stack. It's often recommended to measure at least three things: overall visitor traffic, performance, and uptime. After all, you don't want to be the last to know when your website is trending, unresponsive, or even worse, having downtime. Real user monitoring is the field half. An uptime check is how you hear about a page that never loads.

Field data vs lab data

You can use a variety of tools to measure your Core Web Vitals. While some metrics are easy to measure using lab tools which perform checks in a simulated environment, some of them are best measured using real traffic samples of how visitors interact with each page.

The distinction between the two types of tools is in how they take the measurements. On one hand there is lab data (or synthetic monitoring), which performs checks in a simulated environment, and on the other hand there's field data (or real-user monitoring), which takes measures from the real visitor traffic on a website.

INP and FID need a person at the other end. LCP and CLS can be approximated in the lab, and they still move once real devices and connection speeds get involved.

Tools that support core web vitals

To help get started, here's some of our favourite tools to measure Web Vitals:

No tool will be best suited for every possible scenario, so it's advisable to mix and match the ones that best suit your needs.

Do Core Web Vitals impact search result rankings?

Google's current docs say Core Web Vitals are used by Search's ranking systems, and that there is no single "page experience" signal. The pages to read are Core Web Vitals and Google Search results and Understanding page experience in Google Search results.

The May 2020 post is the announcement that introduced the idea. Search engines generally want to rank websites higher when they offer more relevant, useful content for a given user search. If the content is good, but the website which presents it is unusable, visitors leave. Google's own wording is that the scores are there so you can make the site better for visitors, and that chasing a perfect score only for SEO may not be the best use of the time.

Conclusion

In this guide you've learned what Core Web Vitals are and why are they important. Google's three, scored at the 75th percentile, are LCP, INP, and CLS. We also covered how they affect search result rankings, the differences between field data and lab data, plus some practical tips on how to measure these metrics on your website.

Previous
What is Real User Monitoring (RUM)
Next
What is a "Script Error"