Core Web Vitals probe via PageSpeed Insights
Read the Core Web Vitals of any public URL straight from the Chrome User Experience Report through the Google PageSpeed Insights API. The probe returns the field-data Interaction to Next Paint (INP) that replaced FID as a Core Web Vital in March 2024, alongside LCP, CLS, FCP and TTFB. Mobile and desktop results are shown side by side, with the green / needs-improvement / poor thresholds Google uses for ranking and the Lighthouse lab score for reference.
Requests go directly from your browser to googleapis.com/pagespeedonline/v5 via CORS. The anonymous quota is roughly 4 requests per second; add a PageSpeed API key for higher limits. The URL you test is sent to Google.
What Core Web Vitals mean in 2026 and why INP replaced FID
Core Web Vitals are the three field-data metrics Google uses to score the page experience signal that feeds into search ranking on mobile-first indexing. The trio in 2026 is LCP (Largest Contentful Paint, the loading speed of the largest visible element), INP (Interaction to Next Paint, the responsiveness latency for any user interaction during the page lifetime) and CLS (Cumulative Layout Shift, the visual stability of the page during loading). INP officially replaced First Input Delay (FID) as the responsiveness Core Web Vital on the 12th of March 2024 because INP captures the slowest interaction across the entire session rather than only the first one, which is a far more honest signal of how an application feels.
This probe queries the Google PageSpeed Insights API and reads two layers of data for the URL you submit. The first layer is the Chrome User Experience Report (CrUX), a public dataset of anonymous real-user measurements aggregated over the last 28 days, expressed as the 75th percentile of all visits. The second layer is the Lighthouse lab run, which simulates a load on Google infrastructure and adds extra metrics (FCP, TBT, Speed Index) and a performance score from 0 to 100. The probe colour-codes each metric green, amber or red according to the official Google thresholds and explains in plain English why one of them might be failing.
How the probe works
- Normalise the URL by adding
https://if missing. - Run two PageSpeed Insights requests in parallel: one with
strategy=mobileand one withstrategy=desktop. PSI returns the same CrUX and Lighthouse data for both, so the side-by-side comparison is automatic. - Extract the field metrics from
loadingExperience.metrics: LCP, INP, CLS, FCP and experimental TTFB. Each metric ships its 75th percentile value and the green / needs-improvement / poor bucket distribution. - Extract the lab metrics from
lighthouseResult.audits.metrics.details.items[0]: TBT (Total Blocking Time, the lab proxy for INP), Speed Index, Server Response Time and overall performance score. - Score against Google thresholds and render a visual bar that shows where each value sits between the green/amber/red boundaries. INP under 200 ms is good, 200-500 ms is needs-improvement, above 500 ms is poor; LCP under 2.5 s is good, 2.5-4 s is needs-improvement, above 4 s is poor; CLS under 0.1 is good, 0.1-0.25 is needs-improvement, above 0.25 is poor.
Common use cases for a Core Web Vitals probe
- SEO sign-off before a launch. A site with red CLS or poor INP on mobile cannot rank well in 2026. Run the probe on every public page before announcing a new design.
- Migration verification. After moving to a new CMS, a new server or a new CDN, compare CrUX values before and after over a few weeks; CrUX is rolling 28-day data so the new baseline takes time to settle.
- Vendor due diligence. Before signing with a SaaS that hosts customer-facing pages on its infrastructure, audit the public examples. A vendor with red INP everywhere is a bad bet for your conversion funnel.
- Front-end refactor justification. When asking for time to refactor a heavy SPA, the field INP value is the single most persuasive number to put in the slide deck.
- Competitive teardown. Compare your homepage with the top three competitors on mobile. Even when content quality is similar, the faster site wins clicks.
- Mobile-first audit. Mobile traffic is now the majority for most B2C sites. If the desktop probe is green but the mobile probe is red, the business impact is large and immediate.
Limitations and accuracy notes
The field-data tab uses CrUX, which only has data for URLs that receive enough real Chrome visits. Low-traffic sites and brand-new pages return “No field data available” and only the Lighthouse lab numbers are returned. CrUX is also 28 days rolling, so an improvement deployed yesterday will not show up immediately. The lab numbers come from a single Lighthouse run on Google infrastructure and can vary by 5-15 percent between consecutive runs; treat them as directional rather than absolute. The probe uses the public PageSpeed Insights v5 API which is rate-limited to roughly 4 requests per second per IP without an API key; add your own API key in the field above to raise the limit.
The URL you test is sent to Google as part of the API request, the same way the public PageSpeed Insights web tool would. The PeopleAreGeek server is not involved in the call, and your input is not stored on PeopleAreGeek after the probe completes.
Frequently asked questions
Why does INP matter more than FID?
FID only measured the latency of the very first interaction on a page. INP measures the slowest interaction across the entire session, which is a much better proxy for how the app actually feels. Most users notice the worst interaction, not the first one.
What is a good INP value?
Under 200 milliseconds is good, 200-500 milliseconds is needs-improvement, above 500 milliseconds is poor. The threshold is applied at the 75th percentile of real Chrome users over the last 28 days.
Why does the desktop tab look green but mobile is red?
Mobile devices have slower CPUs and slower networks. Heavy JavaScript bundles that finish parsing in 200 ms on desktop can take 1500 ms on a mid-range Android. The mobile audit is the one Google uses for ranking on mobile-first indexing, so optimise that one first.
What is TBT and why does the lab use it?
Total Blocking Time is the sum of time blocked by long tasks (over 50 ms) between FCP and TTI in the lab. It is the simulator-friendly proxy for INP because the lab cannot record real interactions. A high TBT predicts poor INP in the field.
Do I need a Google API key?
No for occasional checks. The anonymous quota is enough. Add a key (free at console.cloud.google.com, enable PageSpeed Insights API) when you run automated audits.
How long does a CrUX improvement take to appear?
CrUX is 28-day rolling, so a fix deployed today moves the field metric gradually over the next 28 days. A clean comparison usually needs 35-45 days after deployment.
