PageSpeed Insights alternative: Core Web Vitals from your own visitors, page by page

Google PageSpeed Insights is free: give it a URL and it runs a Lighthouse lab test and shows Chrome UX Report field data, eligible Chrome users over 28 days, if the page or its origin has enough of them. AgentFirstStack measures LCP, INP and CLS in your own visitors' browsers on every page with its tracker, low-traffic and signed-in pages included, and an AI agent sets it up; it runs PageSpeed Insights for you too. For a quick check of one public page, or Lighthouse's accessibility and SEO audits, PageSpeed Insights alone is the better tool.

Updated

Set it up with one prompt

Paste this into your coding agent. It starts with a lab run, which works today, and adds the real-visitor numbers that arrive as people visit.

Paste this into Claude Code, Cursor or Codex

Measure this site's Core Web Vitals on every page, from real visitors, with AgentFirstStack Analytics. It's free, open-source analytics built for agents, its tracker reports LCP, INP and CLS for each page load, and you can do the setup yourself: there is no signup form. 1. Read https://agentfirststack.com/llms.txt and https://analytics.agentfirststack.com/llms.txt (the "Page speed" section). 2. If this project's .env already has AGENTFIRSTSTACK_API_KEY, use it and read AGENTFIRSTSTACK.md. Otherwise get a key: curl -X POST https://agentfirststack.com/v1/signup, and save api_key in .env as AGENTFIRSTSTACK_API_KEY and in the production secrets. 3. Use the analytics site in AGENTFIRSTSTACK.md, or create one for the production domain. Serve the tracker from our own domain: a first-party domain (POST https://agentfirststack.com/v1/first-party-domains with a neutral subdomain; add the CNAME if you can change our DNS, otherwise give me the record) or, meanwhile, the path proxy from GET /v1/sites/:id/install. Put the tracker in the head of every page, signed-in pages included. 4. Deploy, open a few pages in a normal browser, and run verify. 5. Run a lab test with GET /v1/sites/:id/web-vitals/lab?strategy=mobile on the homepage and our main landing pages. For each, show me the lab numbers, the top opportunities, Google's field data (google_field: say whether it is for the URL or only the origin) and ours. 6. Read GET /v1/sites/:id/web-vitals?breakdown=page and breakdown=device. If a metric has fewer than 30 page loads, say so and tell me when to look again. List the pages that fail, with the fix you'd make first, and ask me before you change code. 7. Add a web_vitals alert for LCP on mobile to an email destination for me, write the site id and the env var name (never the key) in AGENTFIRSTSTACK.md, and create a claim link for me with POST https://agentfirststack.com/v1/claim-link. Tell me what you set up, what verify and the lab tests returned, what's waiting on me, and give me the claim link.

What PageSpeed Insights is

"PSI provides both lab and field data about a page" (About PageSpeed Insights, as of 7 Nov 2026). The two answer different questions:

  • Lab data is a Lighthouse run "in a simulated environment for the Performance, Accessibility, Best Practices, and SEO categories". For mobile it simulates "a mid-tier device (Moto G4)" on a mobile network; for desktop, an emulated desktop on a wired connection. A performance score of 90 or more is good, 50 to 89 needs improvement, under 50 is poor.
  • Field data comes from the Chrome User Experience Report (CrUX), over the previous 28 days, as the 75th percentile of each metric. A page passes the Core Web Vitals assessment when all three are good. When a page has too little data, PSI falls back to the whole origin, and without enough for that either, it shows no field data.

Who and what CrUX includes (CrUX methodology, as of 7 Nov 2026):

  • Users: Chrome users who turned on usage statistic reporting and sync their browser history without a sync passphrase, on desktop Chrome (Windows, macOS, ChromeOS, Linux) and Android. Not included: "Chrome on iOS", "Android apps using WebView" and "Other Chromium browsers (for example Microsoft Edge)".
  • Pages: "A page must be publicly discoverable": a 200 response, no noindex. And sufficiently popular, with "a minimum number of visitors"; "An exact number is not disclosed". Pages and origins under it aren't in the dataset.

The tool itself, pagespeed.web.dev, is a URL field and an Analyze button, with no sign-in or price. There's also an API. Its guide says Google plans to "discontinue including real-world data from the Chrome User Experience Report" in the API, and recommends the CrUX API or the CrUX History API instead (Get started with the PSI API, as of 7 Nov 2026, no date given).

What your own visitors' data adds

CrUX is Google's sample of Chrome users on popular public pages. Measuring in your own visitors' browsers fills the gaps it leaves:

  • Every page, not only popular ones. New pages, low-traffic pages, campaign landing pages, and pages CrUX can't include at all: signed-in app screens, checkout steps and noindex pages. A page with few page loads gets a rough p75, and AgentFirstStack says so below 30.
  • Your visitors, not only eligible Chrome users. Edge and other Chromium browsers report all three metrics; other browsers report what their performance APIs support. You see which browsers each number rests on.
  • Segments per page. Each page by device, country and browser, filters such as device==mobile or page==/checkout*, and the previous period next to this one.
  • Current numbers. Any period from the last 24 hours up, so you can read the days since a deploy instead of waiting for a 28-day window to roll over.
  • Alerts. A web_vitals alert tells you when a metric's p75 slips over Google's good limit.

What it doesn't change: the Core Web Vitals assessment PageSpeed Insights shows comes from CrUX, so a page can pass for your visitors and still fail there, or the other way round.

How AgentFirstStack does it

Page speed is part of AgentFirstStack Analytics. The tracker records each full page load's LCP, INP and CLS and sends them on the beacon it sends when the visitor leaves the page; single-page-app navigations carry none. Your agent reads them with GET /v1/sites/:id/web-vitals (MCP analytics_get_web_vitals): p75 by Google's method and thresholds, the share of good, needs improvement and poor page loads, sample counts, an assessment, the slowest pages and what usually fixes each failing metric. INP is the slowest interaction, counting interactions over 40 ms, so the dashboard says to read it as an upper bound.

For the lab side it calls PageSpeed Insights itself. GET /v1/sites/:id/web-vitals/lab?url=&strategy=mobile (MCP analytics_get_web_vitals_lab) runs Lighthouse's performance category on one https page of the site and returns:

FieldWhat's in it
labPerformance score, LCP, CLS, Total Blocking Time (the lab stand-in for INP), FCP, Speed Index, server response time
opportunitiesUp to 6 audits with estimated savings, biggest first
google_fieldCrUX p75 for the URL, or the origin, last 28 days; null without data
real_visitorsAgentFirstStack's own p75 for the same path, last 30 days
next_stepsWhat to fix first, and how to check it after the fix

It needs a full-access key, takes 10 to 45 seconds, and is limited to a few runs a minute per account and per domain. It's keyless on Google's shared quota, which can run out for a while (503 upstream_rate_limited). The google_field part comes from the PSI API's answer, so it depends on Google keeping CrUX data there. The page speed overview covers the method in full.

Side by side

PageSpeed InsightsAgentFirstStack Page speed
What it isA Lighthouse lab test plus Chrome UX Report field dataReal-visitor monitoring of LCP, INP and CLS, plus a PageSpeed Insights run on request
Who is measuredEligible Chrome users on desktop and AndroidEvery visitor whose browser reports the metrics
Which pagesPublic, indexable, popular enough; else the origin; else noneEvery page with the tracker, signed-in pages included
WindowThe previous 28 daysAny period; 400 days kept on the hosted service
SegmentsURL or origin; mobile or desktopPage, device, country, browser; filters and period comparisons
Lab auditsPerformance, accessibility, best practices and SEO, every auditPerformance only, with the 6 biggest opportunities
URLs you can testAny public URLHttps pages on the site's own domain and subdomains
SetupNone: paste a URLA tracker on every page; your agent sets it up
Agent accessThe PageSpeed Insights APIREST and MCP, with the same key as analytics, tags, mail and replay
PriceFree, no sign-inFree hosted service with fair-use limits

When to choose which

Use PageSpeed Insights if

  • You want a quick, free check of one public page, yours or anyone's, without installing anything.
  • You want to see what Google's own field data says about a page.
  • You need Lighthouse's accessibility, best practices or SEO audits, or every performance audit in full.

Use AgentFirstStack if

  • PageSpeed Insights shows no field data for the pages you care about, or only the origin's.
  • You need numbers for signed-in pages, checkout steps or campaign landing pages, by device, country and browser.
  • You want to see a fix land soon after the deploy, and be told when a metric slips.
  • Your agent should find the slowest pages, run the lab test on them and propose fixes, over REST and MCP.

Most sites are best served by both: PageSpeed Insights for Google's view and the full Lighthouse report, real-visitor data for every page in between.

Moving from PageSpeed Insights

There's nothing to move: PageSpeed Insights keeps no data for you, and CrUX history stays in Google's own tools. Keep using it. The lab run puts PageSpeed Insights' lab numbers, Google's field data and your real-visitor numbers in one answer, so your agent can see where they disagree.

FAQ

Is PageSpeed Insights free?

Yes. pagespeed.web.dev is a URL field and an Analyze button, with no sign-in and no price. Google also offers a PageSpeed Insights API for running it from code.

Why does PageSpeed Insights show no field data for my page?

Its field data comes from the Chrome UX Report, which includes only pages that are publicly discoverable and sufficiently popular, with a minimum number of visitors Google doesn't disclose. A page that is new or has too few samples falls back to the whole origin's data, or shows none. Real-visitor monitoring on the page measures it from its first visits; under 30 page loads, AgentFirstStack marks the p75 as rough.

Does AgentFirstStack replace Lighthouse?

No. Its lab run calls PageSpeed Insights, which runs Lighthouse, for the performance category only, and returns the score, the lab metrics and the 6 biggest opportunities. For the accessibility, best practices and SEO audits, and every audit in full, use PageSpeed Insights or Lighthouse itself.

Will my numbers match PageSpeed Insights' field data?

Not exactly. Both report the 75th percentile with Google's thresholds, but they measure different visitors over different windows: the Chrome UX Report counts eligible Chrome users on desktop and Android over 28 days, AgentFirstStack every visitor whose browser reports the metrics, over the period you choose. The Core Web Vitals assessment PageSpeed Insights shows is the Chrome UX Report's.

Is Google removing field data from the PageSpeed Insights API?

Google's API guide says it plans to discontinue including Chrome UX Report data in the API, and recommends the CrUX API or the CrUX History API instead. It gives no date. The PageSpeed Insights website isn't named in that note. AgentFirstStack's lab run reads Google's field data from that API's answer, so when it goes, that part comes back null; real-visitor numbers don't depend on it.

Product names belong to their owners. AgentFirstStack isn't affiliated with Google.