Google plans to stop returning CrUX field data from the PageSpeed Insights API. Lab Lighthouse results stay. Here is what to change in your integration before the keys go empty.
Google’s PageSpeed Insights API get-started page now carries a clear warning: they plan to stop including real-world Chrome User Experience Report (CrUX) data in that API, and they point readers at the CrUX API and CrUX History API instead. The Lighthouse lab block (lighthouseResult) is expected to stay. There is still no published removal date. As of early November 2026, PSI responses can still include field objects. That combination is awkward for anyone whose cron, sheet, or microservice treats one PSI call as both lab and field.
If your integration still expects CrUX inside the PageSpeed Insights JSON, the useful work this week is usually not a rewrite of every dashboard. A short audit of which keys you parse, plus a plan to fetch field data from the CrUX endpoints while PSI stays the lab source, is enough to start. One-off PSI screenshots already age badly next to a schedule; that case is covered in PageSpeed Insights vs Automated Monitoring. What “automated” means when lab and field are separate feeds is spelled out in What Is Automated Web Performance Monitoring?.
What Google announced (and what is still missing)
The announcement is an intent line in the docs, not a product post with a sunset calendar. The get-started page says real-world CrUX data will be discontinued from the PageSpeed Insights API and recommends the dedicated CrUX APIs. PageSpeed Insights release notes have not, at the time of writing, published a cutover day or a phased deprecation window.
So the useful posture is simple. Plan for field keys to leave PSI. Keep reading them while they still appear. Avoid shipping new field features that only work if loadingExperience stays forever. Lab diagnostics remain a PageSpeed Insights job.
What breaks if field data still comes from the PSI response
A typical PageSpeed Insights v5 response has carried three related blocks for years: loadingExperience (URL-level CrUX when eligible), originLoadingExperience (origin rollup), and lighthouseResult (the lab run). Many scripts map field LCP, INP, and CLS from the first two and Performance score plus audits from the third. Tutorials and Google’s own older codelabs taught that pattern because it was convenient: one key, one HTTP call, two clocks.
When Google stops embedding CrUX, those first two objects will be empty or absent. Parsers that assume metrics.LARGEST_CONTENTFUL_PAINT_MS.percentile always exists will throw, write nulls, or mark every URL as “no field data” even when CrUX still has the origin. Client boards that mix a lab Performance circle with a field p75 from the same payload become lab-only without anyone changing the site. The awkward part is how quiet that failure is. A lab schedule can look healthy while the field columns go blank, and that is harder to explain in a retainer note than a loud API error.
How to move field reads to the CrUX API
Field data fits better as its own feed rather than as a free side effect of a lab run. Google’s CrUX API guide is the place to start. A working call needs the Chrome UX Report API enabled on a Google Cloud project, a key on every request, and a POST to https://chromeuxreport.googleapis.com/v1/records:queryRecord.
For a whole site, an origin body such as {"origin": "https://example.com"} is enough. For one page, a body like {"url": "https://example.com/pricing", "formFactor": "PHONE"} fits when mobile field matters. The figures teams usually store are percentiles.p75 and the histogram densities for LCP, INP, and CLS. Response shapes differ from PSI’s loadingExperience objects, so a small mapping layer into your own store lasts longer than pretending the JSON matches.
For history and month-over-month field trends, the CrUX History API is the dedicated path. A PSI re-run will not replay last month’s visitors. CrUX field numbers move on a rolling window and update on Google’s cadence; they are not a second Lighthouse run.
Eligibility does not improve because you switched endpoints. Low-traffic URLs and new origins can still return not-found. That is the same CrUX dataset; only the delivery path is moving.
What to keep on the PageSpeed Insights API
PageSpeed Insights remains the right home for what Lighthouse is good at: category scores, opportunities, diagnostics, and a dated lab snapshot for a URL and strategy. A key still helps with quota, and strategy / category still need deliberate choices. Lab schedules stay useful after field moves, because the two answers never meant the same thing.
A clean split looks like this:
| Need | Prefer |
|---|
| Lab Performance score, audits, opportunities | PageSpeed Insights API → lighthouseResult |
| Field p75 / distributions for origin or URL | CrUX API (and History for trends) |
| “Did real users improve after the release?” | Field window + History, not a single PSI lab circle |
Teams that already store full PSI JSON can keep storing the lab half. CrUX responses beside it (or a normalised field row) mean dashboards no longer depend on embedded experience objects forever. A short dual-write window is usually enough to prove the mapping before the old parsers go away.
Prepare checklist before the cut
Most integrations benefit from roughly this order:
- PSI field parsers. Code and sheets that read
loadingExperience or originLoadingExperience, or helpers that assume field lives inside the PSI payload, are the first places to look.
- Field consumers. Reports, Slack bots, warehouses, and boards that paint field p75, overall CrUX category, or “passed Core Web Vitals” from that path all count.
- CrUX API client. The same Google Cloud project family as PSI is fine. The Chrome UX Report API needs to be enabled, and every call needs a key.
- One normalisation step. Mapping CrUX p75 and histogram data into the shape your UI already expects, or tagging rows with
source: crux_api, makes dual-write comparable while PSI still embeds CrUX.
- Dual-write for a while. Reading embedded field while it is present, and also calling CrUX, shows shape and eligibility differences before the cut.
- Origin vs URL policy. Many agency portfolios only need origin-level field daily. URL-level calls cost quota and often 404 on thin pages.
- History where you chart months. Field trends belong on the History API, not on occasional PSI screenshots.
- Runbooks and client copy. “We pull field from CrUX” as the documented path saves a scramble later.
The first four items do not need Google’s cutover date. They are reversible and cheap to try. They stay useful even if the docs remain on “we plan to” for months.
FAQ
Has Google set a date to remove CrUX from the PageSpeed Insights API?
No public cutover date is published yet. The get-started docs state the plan and recommend the CrUX APIs. The change is decided in direction, not dated on a calendar.
Will the PageSpeed Insights website UI lose field data too?
The API docs and programmatic consumers are the scope here. The product UI and release notes deserve a separate watch, because the marketing site and the API may not share the same timeline.
Is CrUX data from the CrUX API the same as PSI field data?
Same underlying CrUX dataset, different delivery and response schema. A short dual-write period is the practical way to see whether parsers need a mapping layer.
Do I still need PageSpeed Insights if I call CrUX directly?
Yes, when you want lab scores and Lighthouse audits. The CrUX API does not run Lighthouse for you.
What if CrUX returns not-found for a client origin?
That is usually eligibility or an identifier mismatch, not proof that lab lied. Matching the public origin string and traffic expectations matters the same way it did when PSI field was empty.
What to do this week
A practical start is one production PSI response your job already stores. If anything customer-facing still reads loadingExperience or originLoadingExperience, a sketch of the CrUX queryRecord call for the same origin (and a place for dual-write) is usually enough for the first afternoon. That is cheaper than discovering empty field columns after the keys disappear from PSI.
For schedules that already separate lab runs from field honesty, the two Watcher posts linked above remain the short path: when manual PSI checks stop scaling, and what automated monitoring is meant to cover.
References
Originally published on Hashnode.