Free tool

Core Web Vitals Checker — How to Check Your Site Free

Diagnose LCP, CLS and Total Blocking Time with Lighthouse lab tests on mobile and desktop. When available, Google CrUX observations show real-user LCP, INP and CLS separately for URL and origin. First Fix prioritises lab evidence; one scan cannot establish a Google Core Web Vitals pass. No signup.

Check Core Web Vitals

Quick answer

How do I improve Core Web Vitals?

Start with the evidence for your page, not a universal fix order. An image LCP element may need earlier discovery or a smaller file; layout shifts need reserved space; long tasks require JavaScript investigation. Google's good field thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1 at the 75th percentile. Lighthouse lab results diagnose issues but cannot establish that field assessment.

LCP target: Under 2.5 s (poor above 4.0 s)
INP target: Under 200 ms (poor above 500 ms)
CLS target: Under 0.1 (poor above 0.25)
What this scan reports: Lighthouse lab data — LCP, CLS and TBT
How Google grades it: 75th percentile of real visits; optional CrUX observations shown separately
First action: Follow the page's eligible First Fix, not a fixed image-first order
Lab blocking diagnostic: Total Blocking Time; not equivalent to INP

What to do next: Retain the first report, review the fix's applicability and use Rescan & Compare for fresh same-device measurements. Results can improve, regress or stay unchanged; one run does not prove causation.

Lab diagnosis and 28-day field observations are different evidence

CrUX reflects a rolling 28-day observation window. URL data describes the tested page; origin data aggregates eligible pages on the same origin and is not evidence for that exact URL. Availability depends on Google's sample; an unavailable metric is not a pass or a failure. Origin data must not be presented as the tested page's own result.

Rescan & Compare obtains fresh Lighthouse lab measurements for the same full URL and device, retaining the original audit evidence. CrUX does not update instantly after deployment and cannot verify an immediate fix. Use the scanner and report comparison for that lab workflow; use the bulk speed test to compare selected URLs.

What counts as a good number, and what each number actually means

These are the thresholds SnapSiteScan grades against, and they match Google's published Core Web Vitals limits. The numbers themselves come from Lighthouse lab data, while Search Console grades the same thresholds on field data from real Chrome visitors — so a pass here is a strong signal, not a guaranteed pass there.

Core Web Vitals and Lighthouse metric thresholds with plain-language meaning and most common cause
Metric	Good	Needs work	Poor	What it means	Usual cause
LCPLargest Contentful Paint	Under 2.5 s	2.5 – 4.0 s	Over 4.0 s	The moment the biggest visible element — usually the hero image or headline — finishes rendering. Visitors read this as “the page has loaded”.Above 2.5 seconds visitors begin noticing the delay. Above 4 seconds many leave before the page finishes loading.	Unoptimised hero image, slow server response, or render-blocking CSS.
INPInteraction to Next Paint (field metric — not measured by a lab scan)	Under 200 ms	200 – 500 ms	Over 500 ms	The delay between a visitor interacting and the screen visibly updating. Above 500 ms the page feels broken rather than slow. INP needs real visitor interactions, so no lab test — SnapSiteScan included — can measure it; Total Blocking Time below is the lab stand-in.Above 200 milliseconds taps feel sluggish. Above 500 milliseconds visitors tap again, believing the page is broken.	Long JavaScript tasks blocking the main thread, often third-party scripts.
CLSCumulative Layout Shift	Under 0.1	0.1 – 0.25	Over 0.25	A unitless score for unexpected movement. It is the metric behind mis-taps and accidental clicks on mobile.Above 0.1 the page visibly moves while being read. Above 0.25 visitors tap the wrong thing, which is how layout shift turns into lost orders.	Images or embeds without reserved width and height, and late-swapping web fonts.
TBTTotal Blocking Time	Under 200 ms	200 – 600 ms	Over 600 ms	A lab diagnostic for long main-thread tasks during loading. It is not observed visitor interaction delay; improving TBT does not guarantee improved field INP.Above 200 milliseconds the page ignores input it appears ready for. Above 600 milliseconds it feels frozen rather than slow.	Large JavaScript bundles, hydration work, tag managers and analytics loading eagerly.
FCPFirst Contentful Paint	Under 1.8 s	1.8 – 3.0 s	Over 3.0 s	The first pixel of real content. A high FCP almost always means the problem is server- or network-side, not front-end code.Above 1.8 seconds visitors are still looking at a blank screen. Above 3 seconds a noticeable share leave before seeing anything at all.	Slow hosting, no caching or CDN, redirect chains, blocking fonts and stylesheets.
SISpeed Index	Under 3.4 s	3.4 – 5.8 s	Over 5.8 s	An average of how complete the page looks over time. It catches pages that show something fast but keep loading for seconds.Above 3.4 seconds the page keeps rearranging itself while being read. Above 5.8 seconds visitors stop waiting for it to settle.	Lazy-loading above-the-fold content, heavy sequential requests, oversized images.

LCPLargest Contentful Paint
Good
Under 2.5 s
Needs work
2.5 – 4.0 s
Poor
Over 4.0 s
The moment the biggest visible element — usually the hero image or headline — finishes rendering. Visitors read this as “the page has loaded”.
Above 2.5 seconds visitors begin noticing the delay. Above 4 seconds many leave before the page finishes loading.
Usual cause: Unoptimised hero image, slow server response, or render-blocking CSS.
INPInteraction to Next Paint (field metric — not measured by a lab scan)
Good
Under 200 ms
Needs work
200 – 500 ms
Poor
Over 500 ms
The delay between a visitor interacting and the screen visibly updating. Above 500 ms the page feels broken rather than slow. INP needs real visitor interactions, so no lab test — SnapSiteScan included — can measure it; Total Blocking Time below is the lab stand-in.
Above 200 milliseconds taps feel sluggish. Above 500 milliseconds visitors tap again, believing the page is broken.
Usual cause: Long JavaScript tasks blocking the main thread, often third-party scripts.
CLSCumulative Layout Shift
Good
Under 0.1
Needs work
0.1 – 0.25
Poor
Over 0.25
A unitless score for unexpected movement. It is the metric behind mis-taps and accidental clicks on mobile.
Above 0.1 the page visibly moves while being read. Above 0.25 visitors tap the wrong thing, which is how layout shift turns into lost orders.
Usual cause: Images or embeds without reserved width and height, and late-swapping web fonts.
TBTTotal Blocking Time
Good
Under 200 ms
Needs work
200 – 600 ms
Poor
Over 600 ms
A lab diagnostic for long main-thread tasks during loading. It is not observed visitor interaction delay; improving TBT does not guarantee improved field INP.
Above 200 milliseconds the page ignores input it appears ready for. Above 600 milliseconds it feels frozen rather than slow.
Usual cause: Large JavaScript bundles, hydration work, tag managers and analytics loading eagerly.
FCPFirst Contentful Paint
Good
Under 1.8 s
Needs work
1.8 – 3.0 s
Poor
Over 3.0 s
The first pixel of real content. A high FCP almost always means the problem is server- or network-side, not front-end code.
Above 1.8 seconds visitors are still looking at a blank screen. Above 3 seconds a noticeable share leave before seeing anything at all.
Usual cause: Slow hosting, no caching or CDN, redirect chains, blocking fonts and stylesheets.
SISpeed Index
Good
Under 3.4 s
Needs work
3.4 – 5.8 s
Poor
Over 5.8 s
An average of how complete the page looks over time. It catches pages that show something fast but keep loading for seconds.
Above 3.4 seconds the page keeps rearranging itself while being read. Above 5.8 seconds visitors stop waiting for it to settle.
Usual cause: Lazy-loading above-the-fold content, heavy sequential requests, oversized images.

What your score means, and whether it is worth fixing

Performance score bands with interpretation and recommended action
Score	Verdict	What it means for your site	What to do
90 – 100	Good	Google's own banding treats this range as good. Speed is unlikely to be what limits rankings or conversions here.	Stop optimising speed. Spend the effort on content and conversion instead.
50 – 89	Needs improvement	Typical for a real business site with a CMS, fonts and a few third-party scripts. Visitors notice the lag on mobile.	Review the first finding ranked by estimated savings, make one applicable change and rescan to measure the outcome. No point gain is guaranteed.
0 – 49	Poor	Google's own banding treats this range as poor. Expect visitors on mobile connections to notice, and some to leave.	Treat it as a structural problem: hosting, image pipeline and script budget, in that order.

The order to fix things in

Every scan ranks your own issues by measured impact. When you have no scan in front of you, this is the default order — cheapest and highest-impact first.

1
Images
Largest share of transferred bytes on most sites and the usual LCP element. Cheapest win per hour spent.
2
Render-blocking CSS and fonts
Delays every paint on the page, so it degrades FCP and LCP at the same time.
3
JavaScript and third-party scripts
Dominates TBT and INP. Removing one unused tag often beats weeks of code tuning.
4
Server response and caching
Sets the floor no front-end fix can get under.
5
Layout stability
Cheap to fix with explicit dimensions, and it directly reduces mis-taps on mobile.

The three metrics Google grades

LCP — Largest Contentful Paint

How fast does the main content appear?

Good: Under 2.5 s
Needs work: 2.5 – 4.0 s
Poor: Over 4.0 s

Usually an unoptimised hero image, a slow server response, or render-blocking CSS.

INP — Interaction to Next Paint

How quickly does the page react when you click?

Good: Under 200 ms
Needs work: 200 – 500 ms
Poor: Over 500 ms

INP requires real visitor interactions, so a Lighthouse lab test cannot measure it. SnapSiteScan reports lab-measured Total Blocking Time (TBT) and, only when available, displays Google's CrUX INP separately as field data. Improving TBT does not guarantee improved field INP.

CLS — Cumulative Layout Shift

Does the layout jump while loading?

Good: Under 0.1
Needs work: 0.1 – 0.25
Poor: Over 0.25

Images or ads without reserved dimensions, and fonts that swap late.

Thresholds follow Google's published Core Web Vitals guidance, which Google evaluates at the 75th percentile of real page loads. This scan reports Lighthouse lab data instead, so treat it as a diagnostic signal rather than the same measurement — see our methodology for how we score.

How the check works

Paste any public URL. You do not need to own the site or install a script.
We run Lighthouse twice. Mobile and desktop are tested in parallel under different controlled device profiles, not as interchangeable scores.
You get one prioritised fix. Instead of an audit dump, you see a finding prioritised by estimated savings, with a code example to review. Rescan to measure the result; no score gain is guaranteed.

Core Web Vitals checker FAQ

What is a Core Web Vitals checker?+

SnapSiteScan diagnoses LCP, CLS and main-thread blocking with Lighthouse lab tests. It displays usable CrUX LCP, INP and CLS observations separately when Google supplies them. TBT is a lab diagnostic, not INP or proof of a Core Web Vitals pass. One scan cannot establish Google's actual field assessment.

Is this Core Web Vitals checker free?+

Yes. No account or credit card. A scan typically takes about 45 seconds. Fair-use limits: 2 scans per minute per IP (10 for bulk requests, 5 for AI requests). Shared request quotas and concurrent-request limits also apply across the service, independently of IP headers. Fresh scans do not bypass these limits. When capacity or protection is unavailable, new requests pause; existing reports remain readable.

Does it use lab data or field data?+

SnapSiteScan reports Google Lighthouse lab data from the PageSpeed Insights API — a controlled test on a simulated mobile and desktop device. When the same API response contains usable Chrome User Experience Report observations, they are shown separately as URL-level or origin-level field data, never included in the Website Health score. Search Console grades Core Web Vitals on field data from real Chrome visitors. A lab result is a strong indicator of the same underlying problems, but it is not the same measurement and can pass or fail differently.

Do Core Web Vitals affect Google rankings?+

Google uses Core Web Vitals in its ranking systems, but good metrics do not guarantee visibility or outrank relevant content. Lighthouse scores are not Google's field assessment. Fix performance for the visitor experience, not a promised ranking gain.

How often should I check Core Web Vitals?+

After every meaningful deploy, and at minimum monthly. Third-party scripts, new images and plugin updates degrade vitals silently between releases.