Core Web Vitals Checker (INP, LCP, CLS)

What Core Web Vitals mean in 2026 and why INP replaced FID

Core Web Vitals are field-data numbers Google leans on for its page-experience signal, the one feeding mobile-first ranking. In 2026 there are three that count. LCP, Largest Contentful Paint, is how fast your biggest visible element actually shows up. INP, Interaction to Next Paint, is how long the page makes someone wait after a tap or a click. CLS, Cumulative Layout Shift, is whether stuff jumps around while the page loads. INP took over from First Input Delay on March 12, 2024, and honestly it was overdue. FID only ever clocked the first interaction. INP watches the worst one across the whole visit, which lines up a lot closer to how an app feels in your hand.

Under the hood I hit Google's PageSpeed Insights API and read two completely different layers for whatever URL you give me. First layer: CrUX, the Chrome User Experience Report. That's anonymous data from real Chrome users, rolled up over the trailing 28 days and reported at the 75th percentile. It's the data Google actually ranks on, so it's the one I care about most, by a wide margin. Second layer: a Lighthouse lab run on Google's own hardware. It throws in extras like FCP and TBT and Speed Index, plus a 0-to-100 score. Every metric gets painted green, amber or red against Google's thresholds. Where one's failing, I tell you in plain English why, no jargon dump.

How the probe works

1. Normalise the URL. Forgot the https://? I tack it on for you.
2. Run two PageSpeed Insights requests in parallel, one strategy=mobile and one strategy=desktop. PSI hands back the same CrUX and Lighthouse payload for each, so the side-by-side comparison costs you nothing extra.
3. Extract the field metrics from loadingExperience.metrics. That's LCP, INP, CLS, FCP and the experimental TTFB, and every one arrives with its 75th-percentile value plus the green / needs-improvement / poor split.
4. Extract the lab metrics from lighthouseResult.audits.metrics.details.items[0]: TBT (Total Blocking Time, which the lab uses as a stand-in for INP), Speed Index, Server Response Time and the overall score.
5. Score against Google thresholds and draw a little bar showing where each value lands in the green/amber/red zones. The lines, in case you forgot them: INP is good under 200 ms, shaky from 200 to 500 ms, poor past 500 ms. LCP good under 2.5 s, shaky to 4 s, poor beyond. CLS good under 0.1, shaky to 0.25, poor above.

Common use cases for a Core Web Vitals probe

• SEO sign-off before a launch. Ship a redesign with red CLS or poor mobile INP and you're quietly handing rankings to a competitor. So I run this on every public page before a new design goes live. Every time, no skipping it.
• Migration verification. Moved to a new CMS or server or CDN? Snapshot the CrUX numbers first, then keep an eye on them over the following weeks. It's rolling 28-day data, so the new baseline won't show up overnight. Patience.
• Vendor due diligence. Before you sign with a SaaS that'll host your customer-facing pages, point this at their public demos. If their own INP is red across the board, well, that's the conversion funnel you're about to inherit.
• Front-end refactor justification. Trying to win time to untangle a bloated SPA? Put the field INP number on the slide. I've never found anything that moves a budget conversation quicker.
• Competitive teardown. Line your homepage up against your top rivals on mobile. The content can be a total wash and the faster page still takes the clicks.
• Mobile-first audit. For most B2C sites, mobile is where the traffic actually lives now. Desktop green but mobile red? You're leaking money, and not in some hypothetical future, today.

Limitations and accuracy notes

Straight talk about what this can and can't tell you. The field tab runs on CrUX, and CrUX only carries numbers for URLs with enough real Chrome traffic behind them. Low-traffic or freshly-launched pages come back "No field data available" and all you'll see is the Lighthouse lab figures. CrUX is that 28-day rolling window too, so a fix you shipped yesterday won't have budged it yet. The lab side is a single Lighthouse run on Google's hardware. I've watched it swing 5 to 15 percent between back-to-back runs on the same URL, so treat it as a direction of travel and not a verdict. And the whole thing rides the public PageSpeed Insights v5 API, capped near 4 requests per second per IP without a key. Hitting that wall? Paste your own key in the field above.

One thing worth spelling out: the URL you test goes to Google as part of the request, same as it would on Google's own PageSpeed Insights page. My server never touches the call. Nothing you type sticks around on PeopleAreGeek once the probe finishes.

Frequently asked questions

Why does INP matter more than FID?

FID only ever timed your very first interaction on the page. One tap, done. INP keeps watching and grabs the slowest interaction across the whole visit, which lines up a lot better with how the thing actually feels to use. Nobody really remembers the first click. The one that hung for half a second, though, that one sticks.

What is a good INP value?

Under 200 milliseconds is the good zone. 200 to 500 is needs-improvement, anything past 500 is poor. Here is the catch most people miss. Google checks it at the 75th percentile of real Chrome users over the trailing 28 days. Your median feeling snappy is not enough on its own. The slowest quarter of your visitors has to be in decent shape, and that is the bit that usually bites.

Why does the desktop tab look green but mobile is red?

Weaker CPUs, flakier networks. That is basically the whole story. A JavaScript bundle that parses in 200 ms on your dev machine can chew up 1500 ms on the mid-range Android someone actually carries around. And the part that stings, it is the mobile score Google ranks on under mobile-first indexing. Fix mobile first. A green desktop is nice to have, sure, but it is not what is bringing you traffic.

What is TBT and why does the lab use it?

Total Blocking Time sums up every stretch the main thread sat jammed by long tasks, anything over 50 ms, between FCP and TTI in the lab. The lab cannot actually click anything, so it cannot measure INP directly. TBT is the best stand-in it has got. My rough rule, and I could be overstating the correlation, is that a high TBT in the lab usually points to a poor INP out in the field. Usually. Not a law.

Do I need a Google API key?

For the odd spot-check? No. The anonymous quota carries you fine. A key only earns its keep once you are scripting audits in a loop and bumping the rate limit. It is free either way. You grab one at console.cloud.google.com and switch on the PageSpeed Insights API.

How long does a CrUX improvement take to appear?

Slower than you would like. CrUX rolls a 28-day window, so a fix you ship today only nudges the field number bit by bit as the old days age out of the sample. I would not trust a clean before-and-after until somewhere around 35 to 45 days post-deploy. Day three, I once called a win that was not. Lesson learned.