Free tool · no signup

Website Speed Checker

Run a real Core Web Vitals test — LCP, INP and CLS — in plain language, with the top three fixes.

In short

The Website Speed Checker runs a Google PageSpeed Insights test on any public URL and reports the three Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift — against Google's official thresholds. It returns a pass or fail for each, an overall grade, and the specific fixes with the largest measured saving. It is free and needs no signup.

Device

Google assesses mobile and desktop separately. Mobile is usually the harder of the two.

What is a good Core Web Vitals score?

Google's thresholds are: Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. A page passes Core Web Vitals only when all three are met at the 75th percentile of real visits, measured separately for mobile and desktop — so three quarters of your visitors must get that experience, not the average one.

What each Core Web Vital actually measures

Largest Contentful Paint is when the biggest thing on screen finishes rendering — usually a hero image, a video poster or a large block of text. It is a proxy for the moment the page stops looking empty. A slow LCP is nearly always one of four things: a slow server response, a render-blocking stylesheet or script, an oversized or late-loading hero image, or client-side rendering that delays the main content until JavaScript has run.

Interaction to Next Paint measures responsiveness: from a tap or click to the next frame the browser paints in response. It captures the whole interaction, not just the initial delay, and reports close to the worst interaction on the page. High INP means the main thread is busy — long JavaScript tasks, heavy event handlers, or large re-renders blocking the browser from drawing anything.

Cumulative Layout Shift measures visual stability: how much content moves after it has been painted. The usual culprits are images and iframes without width and height attributes, ads or embeds injected into the flow, and web fonts that reflow text when they swap in.

The thresholds, exactly

Google publishes a specific threshold for each metric and a specific way of applying it. A page is assessed at the 75th percentile of real page loads over a 28-day window, split by device type. Passing on the average is not passing — the point of the 75th percentile is that a poor experience for a quarter of visitors should not be hidden by a fast one for the rest.

  • LCP — good at 2.5s or less, needs improvement to 4.0s, poor above 4.0s
  • INP — good at 200ms or less, needs improvement to 500ms, poor above 500ms
  • CLS — good at 0.1 or less, needs improvement to 0.25, poor above 0.25

The fixes that usually pay off first

Start with the hero image, because it is the most common LCP element and the easiest to get wrong. Serve it in a modern format, size it to the space it actually occupies, and never lazy-load it — a lazy-loaded LCP image is a self-inflicted delay of several hundred milliseconds. Adding a preload hint for it usually helps more than anything else on the page.

Then look at what blocks rendering. Third-party scripts — tag managers, chat widgets, analytics, A/B testing tools — are the single largest source of both slow LCP and high INP on ordinary business sites, because each one is JavaScript the browser must fetch and run before it can get on with the page. Loading them asynchronously, or deferring them until after first paint, usually recovers more than any amount of image optimisation.

For layout shift, set explicit width and height on every image and iframe, reserve space for anything injected after load, and use font-display with a matched fallback so text does not reflow when the web font arrives.

Frequently asked questions

What is a good Core Web Vitals score?

LCP of 2.5 seconds or under, INP of 200 milliseconds or under, and CLS of 0.1 or under. Between 2.5 and 4 seconds LCP, 200 and 500 milliseconds INP, or 0.1 and 0.25 CLS is 'needs improvement'. Above those upper bounds is poor. All three must pass, at the 75th percentile of real user visits.

What is the difference between field data and lab data?

Field data comes from the Chrome User Experience Report — real Chrome users on real connections and devices, over the previous 28 days. Lab data is a single simulated load run on demand. Field data is what Google uses to assess your page, but it only exists once a URL has enough traffic; lab data is always available and is what you debug against.

Why is my score different every time I run the test?

Lab results vary because each run is a fresh simulated load on shared infrastructure, so network timing and CPU contention differ between runs. Field data does not fluctuate like that — it moves slowly because it is a 28-day rolling window of real visits. If you need a stable number, use the field data.

Does page speed affect Google rankings?

Yes, but modestly. Google has confirmed Core Web Vitals are a ranking signal within its page experience signals, while stating that relevance and content quality carry far more weight. Speed rarely lifts a page above a better-matching result — it more often decides between pages that are otherwise close.

What replaced First Input Delay?

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. FID measured only the delay before an interaction started processing; INP measures the full time from interaction to the next visual update, across all interactions on the page, which reflects what a user actually experiences.

More free tools

See all 8 free tools — no signup on any of them.

See it live

See this kind of instant response live

SpideyChat is an AI employee for your website — it answers customers from your own content, day or night, and captures the enquiries that would otherwise wait until morning. Try the demo; it needs no account either.