Free tool
Core Web Vitals Checker
Check your Core Web Vitals thresholds — LCP, CLS and the lab stand-in for INP — on mobile and desktop in about 45 seconds. The check runs on Google Lighthouse lab data, the same engine behind PageSpeed Insights, and returns the one fix that will move your scores the most. No signup.
Check Core Web VitalsQuick answer
How do I improve Core Web Vitals?
Improve Core Web Vitals by fixing them in the order they are usually broken: compress and correctly size the largest above-the-fold image to fix LCP, reserve explicit width and height on every image and embed to fix CLS, and remove or defer the heaviest third-party script to fix INP. A page passes Core Web Vitals only when LCP is under 2.5 seconds, INP is under 200 milliseconds and CLS is under 0.1 — all three at the 75th percentile of real visits, as graded by Google on field data.
- 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 (field data, not read here)
- Fastest single win
- Compressing the hero image
- Lab stand-in for INP
- Total Blocking Time, under 200 ms
What to do next: Scan the page, fix only the top-ranked recommendation, then re-scan to confirm the metric moved before touching anything else.
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.
| 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 | The lab stand-in for INP: total time the main thread was busy enough to ignore input. Fix TBT and INP follows.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. |
What your score means, and whether it is worth fixing
| 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. | Fix the single highest-impact issue — usually images or blocking JavaScript. One change often moves 10–20 points. |
| 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
Long JavaScript tasks blocking the main thread — often third-party scripts. INP needs real visitor interactions, so no lab test measures it. We report Total Blocking Time instead, which comes from the same cause.
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, because Google indexes mobile-first but your customers use both.
- You get one prioritised fix. Instead of an 80-item audit dump, you see the single change with the largest predicted score gain — with a copy-paste snippet attached.
Core Web Vitals checker FAQ
What is a Core Web Vitals checker?+
A Core Web Vitals checker measures the metrics Google uses to judge page experience — LCP, INP and CLS — and tells you whether each one passes. SnapSiteScan runs Google Lighthouse on both mobile and desktop and reports LCP, CLS and Total Blocking Time. INP itself can only be measured from real visitor interactions, so it is not part of a lab scan; TBT is its lab stand-in.
Is this Core Web Vitals checker free?+
Yes. No account and no credit card. Paste a URL and you get the report in about 45 seconds. Scanning is rate-limited to 2 scans per minute per IP address to keep the service free for everyone.
Does it use lab data or field data?+
Lab data only. The scan reports Google Lighthouse lab results from the PageSpeed Insights API, measured under an emulated mobile device and throttled network. SnapSiteScan does not read Chrome User Experience Report field data. Field data in Search Console comes from real Chrome visitors over 28 days, so the two numbers will differ. Lab data is what you use while fixing; field data is what Google ranks on.
Do Core Web Vitals affect Google rankings?+
Yes, as part of Google's page experience signals. They rarely outrank relevance or content quality, but between two comparable pages the faster, more stable one has the advantage — and users bounce less.
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.