Free tool
Core Web Vitals Checker
Check your Core Web Vitals — LCP, INP and CLS — on mobile and desktop in about 30 seconds. The check runs on Google Lighthouse, the same engine behind PageSpeed Insights, and returns the one fix that will move your scores the most. No signup, no scan limit.
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.
- 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)
- Measured at
- 75th percentile of real user visits
- Fastest single win
- Compressing the hero image
- Lab equivalent of 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. They match Google's published Core Web Vitals limits, so a passing result here is a passing result in Search Console.
| 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 | 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.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 | The page is in roughly the fastest quarter of the web. Speed is no longer 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 | The page is slower than the large majority of the web. Expect measurable bounce on mobile connections. | 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 we check
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.
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, evaluated at the 75th percentile of page loads. Lighthouse produces lab data — 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 three metrics Google uses to judge page experience — LCP, INP and CLS — and tells you whether each one passes. SnapSiteScan runs the check through Google Lighthouse on both mobile and desktop, then ranks what to fix first.
Is this Core Web Vitals checker free?+
Yes. No account, no credit card, no scan limit. Paste a URL and you get the full Core Web Vitals report in about 30 seconds.
Does it use lab data or field data?+
The scan reports Google Lighthouse lab data, measured under an emulated mobile device and throttled network. Field data in Search Console comes from real Chrome users 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.