Core Web Vitals probe via PageSpeed Insights
Paste a public URL. I’ll pull its Core Web Vitals straight from the Chrome User Experience Report through Google’s PageSpeed Insights API, no signup, nothing to install. You get the real-world Interaction to Next Paint (INP), the metric that knocked FID off the list back in March 2024, and you get LCP, CLS, FCP and TTFB too. Mobile and desktop run side by side so the gap between them jumps right out. Everything’s colored against the same green / needs-improvement / poor lines Google ranks on, and I throw in the Lighthouse lab score for a second opinion.
Your browser hits googleapis.com/pagespeedonline/v5 over CORS. I’m not in the middle. Anonymous gets you roughly 4 requests a second, which is plenty for a spot-check; if you need more headroom, drop a PageSpeed API key in the field. One heads-up though, the URL you test does go to Google.
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
- Normalise the URL. Forgot the
https://? I tack it on for you. - Run two PageSpeed Insights requests in parallel, one
strategy=mobileand onestrategy=desktop. PSI hands back the same CrUX and Lighthouse payload for each, so the side-by-side comparison costs you nothing extra. - 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. - 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. - 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-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-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-500 is needs-improvement, anything past 500 is poor. Here’s 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 isn’t enough on its own. The slowest quarter of your visitors has to be in decent shape, and that’s the bit that usually bites.
Why does the desktop tab look green but mobile is red?
Weaker CPUs, flakier networks. That’s 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’s the mobile score Google ranks on under mobile-first indexing. Fix mobile first. A green desktop is nice to have, sure, but it’s not what’s 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 can’t actually click anything, so it can’t measure INP directly. TBT is the best stand-in it’s 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’re scripting audits in a loop and bumping the rate limit. It’s 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’d 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 wouldn’t trust a clean before-and-after until somewhere around 35-45 days post-deploy. Day three, I once called a win that wasn’t. Lesson learned.
