SnapSiteScan — Find Your First Fix

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.

• 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

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. 1

   Images

   Largest share of transferred bytes on most sites and the usual LCP element. Cheapest win per hour spent.

2. 2

   Render-blocking CSS and fonts

   Delays every paint on the page, so it degrades FCP and LCP at the same time.

3. 3

   JavaScript and third-party scripts

   Dominates TBT and INP. Removing one unused tag often beats weeks of code tuning.

4. 4

   Server response and caching

   Sets the floor no front-end fix can get under.

5. 5

   Layout stability

   Cheap to fix with explicit dimensions, and it directly reduces mis-taps on mobile.