Skip to content
SEO Madmanby Adam Hafez
Free tool

Core Web Vitals checker for LCP, INP and CLS scores

Core Web Vitals checker: rate LCP, INP and CLS values as Good, Needs improvement or Poor and see if all three pass. Free, runs in your browser.

Runs entirely in your browser. Nothing you enter is uploaded, logged or stored.

Enter all three metrics to see the overall assessment.

This tool does not measure a live page. Enter numbers you already have, from a source such as PageSpeed Insights or the Chrome UX Report, and it classifies them against Google's published thresholds. Google's real Core Web Vitals assessment runs over the 75th percentile of a distribution of real-user visits, not a single number, so a pass here is a classification of your input, not a substitute for that field assessment. Everything runs in your browser; nothing is sent anywhere.

Key takeaways

  • A page passes the Core Web Vitals assessment only when LCP, INP and CLS all meet their Good thresholds at the 75th percentile.
  • The Good thresholds are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS.
  • Poor starts above 4.0 seconds for LCP, above 500 milliseconds for INP and above 0.25 for CLS.
  • A value exactly on a threshold counts as the better rating, so an LCP of 2.5 seconds is Good.
  • This tool classifies whatever number you type, so a pass here reflects your input, not a field measurement of your site.

What it takes

  • Largest Contentful Paint, in seconds
  • Interaction to Next Paint, in milliseconds
  • Cumulative Layout Shift, a unitless score

More tools

All of them free, all of them browser-only.

Browse the tools

How to use it

  1. 1Get your numbers firstThis tool does not crawl or measure anything. Pull real numbers from PageSpeed Insights, the Chrome UX Report, or your own real-user monitoring before you use it.
  2. 2Enter LCP in secondsLargest Contentful Paint is the time until the biggest visible element renders. Type the value in seconds, such as 2.1.
  3. 3Enter INP in millisecondsInteraction to Next Paint measures how quickly the page responds to user interactions such as clicks, taps and key presses, in milliseconds.
  4. 4Enter CLS as a scoreCumulative Layout Shift is a unitless score describing how much visible content moved unexpectedly. Lower is better.
  5. 5Read the per-metric ratingsEach metric gets its own Good, Needs improvement or Poor rating against the published thresholds, shown under the inputs.
  6. 6Read the overall resultThe page only passes when all three metrics are Good. A single Poor or Needs improvement metric fails the overall assessment.

Core Web Vitals are three metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. web.dev publishes a Good and a Poor threshold for each, and a page passes only when it meets the Good target for all three at the 75th percentile of page loads. This checker applies those thresholds to numbers you already have. It does not crawl, load or measure your page.

What the checker checks

Each value is rated against the thresholds on web.dev:

MetricGoodNeeds improvementPoor
LCP (seconds)2.5 or lessabove 2.5 up to 4.0above 4.0
INP (milliseconds)200 or lessabove 200 up to 500above 500
CLS (score)0.1 or lessabove 0.1 up to 0.25above 0.25

Boundaries count toward the better rating: 2.5 seconds is Good, 4.0 seconds is Needs improvement, 4.1 is Poor. A blank field or a negative number is treated as not entered.

INP replaced First Input Delay as the responsiveness Core Web Vital in 2024, so older reports and tools that still show FID cannot be used for this check.

How to read the results

Under the inputs, each metric shows its value and a rating in green, amber or red. The overall line waits until all three are filled in, then gives one of two answers:

  • Pass. All three are Good. The tool adds that Google’s real assessment still needs this held at the 75th percentile across real visits, not just one measurement.
  • Fail. At least one metric is Needs improvement or Poor. A single amber metric fails the whole assessment, which matches how web.dev defines passing.

Treat a pass as a threshold check on the numbers you typed. If they came from one lab run, the field data for the same page can differ.

Worked example

Suppose PageSpeed Insights field data for a product page shows an LCP of 2.1 seconds, an INP of 250 milliseconds and a CLS of 0.05. Enter them and the tool returns:

  • LCP: 2.1s, Good
  • INP: 250ms, Needs improvement
  • CLS: 0.05, Good

The overall line reads that these numbers do not pass, because Google only counts a page as Good when LCP, INP and CLS are all in the Good range at once. The loading and layout work is done; the page fails on responsiveness alone. Bring INP to 200 milliseconds or less, for example 180, and the overall result turns to a pass.

Common mistakes it catches

  • Averaging instead of the 75th percentile. An average can sit comfortably inside Good while the slowest quarter of visits does not. Enter the 75th percentile value your report gives.
  • Treating two out of three as a pass. Good LCP and CLS do not offset a Needs improvement INP.
  • Unit slips. LCP is entered in seconds and INP in milliseconds. Typing an LCP of 2100 rates it Poor, which is a quick sign the unit is wrong.
  • Reading a lab CLS as final. web.dev notes that layout shifts within 500 milliseconds of a user input can be excluded, and scrolls do not count as recent input, so real sessions can score differently from a load-only lab test.
  • Checking one device. web.dev segments the 75th percentile across mobile and desktop. Enter each set separately.

Sources

  1. 1.Largest Contentful Paint (LCP) - web.dev, Chrome teamPrimary
  2. 2.Interaction to Next Paint (INP) - web.dev, Chrome teamPrimary
  3. 3.Cumulative Layout Shift (CLS) - web.dev, Chrome teamPrimary
  4. 4.Core Web Vitals - web.dev, Chrome teamPrimary

Frequently asked questions

What are good Core Web Vitals scores?

An LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, per web.dev. Values above 4.0 seconds, 500 milliseconds and 0.25 respectively are Poor, and anything in between needs improvement.

Does this tool test my website's speed?

No. It rates numbers you type in. To get the numbers, run the page through PageSpeed Insights, look up its Chrome UX Report data, or use your own real-user monitoring, then enter the values here.

Why does Google use the 75th percentile?

web.dev recommends measuring at the 75th percentile of page loads, segmented across mobile and desktop, so the target is met for most users rather than for an average visit. A page passes when all three metrics meet their targets at that percentile.

What happened to First Input Delay?

INP replaced First Input Delay as the Core Web Vital for responsiveness in 2024. If a report still shows FID, it is out of date; enter the INP value instead.

Is a lab result from Lighthouse good enough?

It is useful for debugging, but the assessment web.dev describes is based on real page loads at the 75th percentile. A single lab run can land on either side of a threshold that field data does not.