DEV Community

Cover image for CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History
Apogee Watcher
Apogee Watcher

Posted on • Originally published at apogeewatcher.com

CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History

#webdev #webperf #seo

For years the CrUX Dashboard was the bookmark agencies opened when a client asked whether field Largest Contentful Paint had moved since the last deploy. It was a Looker Studio report on monthly Chrome User Experience Report (CrUX) data: stacked bars for origin-level distributions, a familiar place to screenshot TTFB, Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) without writing SQL. Google retired it at the end of November 2025 and shut down the shared CrUX Connector that fed it. If your team still has a saved link, the chart either fails to load or stops at the last month the connector received.

The Chrome UX Report itself did not go away. What you need now is a replacement stack: CrUX Vis and the CrUX History API for TTFB, INP, and CLS trends, PageSpeed Insights and Search Console for the latest field slice, BigQuery if you want years of origin history on your own billing project, and scheduled lab monitoring so deploy proof does not wait on CrUX's 28-day rolling window. No single free dashboard copies every old Looker view, but the migration path is straightforward once you match each tool to the question you are actually asking.

Why Google retired the CrUX Dashboard and Looker Studio connector

Google announced the deprecation in September 2025. The CrUX Dashboard was a Chrome team-maintained Looker Studio template on monthly CrUX tables. Usage grew after Core Web Vitals became a ranking signal in 2020, but the connector behind it struggled with outages, especially around monthly data releases. Google pointed teams at the CrUX History API (weekly series, up to about 40 points) and CrUX Vis (first-party charts on that API) as more reliable paths.

By November 2025 the connector stopped receiving new months. Dashboards that depended on Google's shared BigQuery bridge stopped updating; CrUX release notes treated that as the final reminder. You can still run the old Looker template against your own chrome-ux-report BigQuery project if you accept query cost and setup work, but the free one-click version most teams used is not coming back. CrUX Vis now carries much of the same job with weekly points instead of monthly bars, and PageSpeed Insights still shows the latest rolling 28-day field slice when Google has enough Chrome traffic for the origin or URL.

PageSpeed Insights field data and Search Console: current Chrome UX Report numbers

When someone asks "what does CrUX say right now?", they usually want the latest rolling field percentiles, not six months of history. Three surfaces answer that question most often, and they share the same underlying dataset with different filters and presentation. PageSpeed Insights, Search Console, and the daily CrUX API each emphasise a different workflow, but the numbers trace back to the same Chrome User Experience Report collection rules.

PageSpeed Insights field data for one origin or URL

PageSpeed Insights is still the default check for a single origin or URL. Open PageSpeed Insights, run the test, and read the field section when CrUX has eligible traffic. You get origin-level and, when sample size allows, URL-level p75 values for Core Web Vitals and supporting metrics, including experimental field Time to First Byte (TTFB) where Google publishes it. Lab Lighthouse numbers on the same screen are synthetic; field numbers are the 28-day rolling average described in why your Core Web Vitals fix is not in CrUX yet.

PageSpeed Insights lab data versus field data on the same URL

PageSpeed Insights shows lab and field on one page, which is convenient and easy to misread. Lab data is a controlled Lighthouse run on demand: fixed device profile, emulated network, one load you triggered. Field data is CrUX: real Chrome users over roughly the past 28 days, blended across devices, cache states, and journeys. A green lab Performance score beside an amber field INP band is normal after a deploy, on a low-traffic URL, or when third-party scripts behave differently for real users than in the lab.

Lab (Lighthouse in PageSpeed Insights) Field (CrUX in PageSpeed Insights)
Source Synthetic test you run Opted-in Chrome sessions
Clock Same day, every run 28-day rolling average
Best for Deploy verification, before/after on priority URLs SEO reporting, client field status
Replaces CrUX Dashboard history? No (point-in-time unless you store runs) No (latest period only; use CrUX Vis or History API for trends)

Treat the two blocks as complementary, not competing scores. Lab answers whether the change shipped cleanly; field answers whether enough real users have lived with it for the aggregate to move. For a fuller split between synthetic schedules and real-user monitoring, see synthetic versus real user monitoring. The CrUX Dashboard retirement does not remove that distinction; it removes one place that charted field history without opening PageSpeed Insights, CrUX Vis, or an API client.

Search Console Core Web Vitals report for SEO workflows

Search Console's Core Web Vitals report groups URLs by status (Good, Needs improvement, Poor) at origin granularity for SEO workflows. It is slower to navigate than PageSpeed Insights for one URL, but account managers already live there for indexing and query data. Field metrics inherit the same CrUX eligibility rules: low-traffic pages may show origin-only data or gaps, which we will unpack further in a later post on missing CLS and INP in PageSpeed Insights.

Daily CrUX API for the latest field collection period

The daily CrUX API (queryRecord endpoint) returns the same latest collection period programmatically. Use it when you want to store today's field p75 beside yesterday's in your own database, or when a script needs TTFB, INP, or CLS without opening a browser. It refreshes roughly daily with a short processing lag; it does not return the long weekly history that the History API exposes.

Need Tool Granularity History
Quick check on one URL PageSpeed Insights Origin + URL when eligible Latest 28-day period only
SEO reporting by URL group Search Console CWV report Origin / URL groups Status trends, not full metric export
Automation for "today's field" CrUX API queryRecord Origin or URL One collection period per call
Metric definitions and thresholds [Core Web Vitals guide](https://apogeewatcher.com/blog/what-are-core-web-vitals-a-practical-guide-for-2026) Reference N/A

CrUX Vis and the CrUX History API: TTFB, INP, and CLS field history

The old CrUX Dashboard's real value was trend lines: did INP drift after the tag manager change, did TTFB step up when the CDN rule shipped, did CLS calm down after the font fix? Current field snapshots in PageSpeed Insights answer "where are we this week?" History answers "when did it start moving?" Those are different tools now, and most teams need both answers on retainer accounts.

CrUX Vis for weekly field trend charts

CrUX Vis is Google's direct replacement UI. Point it at an origin or URL and open the Core Web Vitals, Loading Performance, Interactivity, or Visual Stability pages. Each chart shows weekly distributions built from the CrUX History API, with each point covering the previous 28 days of Chrome experiences. Data updates on Mondays; you can see up to about 40 weeks where Google has samples. TTFB sits with loading metrics; INP with interactivity; CLS with visual stability. CrUX Vis is free, fast compared with the old Looker report, and enough for a quarterly business review on one domain. It still queries one origin or URL at a time, so it does not replace a spreadsheet of fifty client homepages.

Query the CrUX History API for programmatic field history

The CrUX History API (queryHistoryRecord) powers CrUX Vis and any custom chart you build. With a Google Cloud API key you can pull weekly time series for origins and, critically, for URLs that qualify, which monthly BigQuery alone did not make easy for page-level history. Set collectionPeriodCount up to 40 to match the Vis window. Pair History API calls with daily queryRecord calls when you want both "what happened over the last six months" and "what changed since Tuesday's deploy." Google's History API guide documents form factors, histogram densities, and collection period dates; put those dates on client slides so nobody mistakes a four-week blend for a live score.

BigQuery for long-archive Chrome UX Report analysis

BigQuery (chrome-ux-report public dataset) remains the long-archive option. Monthly tables still publish for deep analysis, competitive research, and custom Looker Studio reports on your own billing account. Load times are slower and the data is less current than the APIs, but you can join CrUX to analytics exports, slice by country or device tables, and keep years of origin history that exceed the History API window. Expect to pay for queries after the free tier unless you cache results. Some newer sub-metrics appear in APIs before every BigQuery table catches up; check CrUX release notes when you standardise a metric set for client reports.

CrUX Vis, CrUX History API, or BigQuery: which fits your question?

Teams often ask for one replacement tool. In practice you pick by question, budget, and who needs to open the chart. Use CrUX Vis when a technical lead or SEO owner needs a trustworthy trend for one priority origin or URL and nobody wants to maintain a script. It is the fastest honest answer to "show me INP over the last few months" in a client call. Use the History API when you need the same series inside your own dashboard, a weekly email, or a database next to deploy tags. Use BigQuery when the question needs custom SQL, long horizons, or joins that Google's UI will never ship. Use PageSpeed Insights or the daily API when the question is simply whether today's field p75 cleared the budget.

None of these options shorten the 28-day rolling window. A fix shipped yesterday still ages into field aggregates gradually, which is why scheduled lab monitoring matters during the lag. PageSpeed Insights versus automated monitoring covers that split for teams who outgrew manual checks; the CrUX retirement does not remove the need for a lab clock beside the field clock.

Third-party Chrome UX Report tools for agency portfolios

Google is not the only place to chart CrUX. Several products wrap the History API or BigQuery with alerts, competitor views, and multi-URL boards. Treo is a common example for agencies that want CrUX-heavy field exploration and large URL lists without building pipes themselves. Field explorers and scheduled PageSpeed monitoring solve different jobs, and many teams use both. For how agencies shortlist monitoring tools on features and workflow fit, see comparing PageSpeed monitoring tools.

Apogee Watcher sits on the scheduled lab side of that split. We run PageSpeed Insights-backed tests across many sites on a cadence you set, store LCP, INP, CLS, FCP, and Total Blocking Time from lab runs, and show CrUX field numbers beside those results when Google returns them for the URL. We do not replace CrUX Vis for a six-month INP line chart on one domain, and we do not replicate BigQuery. We do give agency portfolios a repeatable before-and-after history on priority pages, budgets, and alerts while field data catches up, layered onto Search Console and the explorers you already use.

Field pipelines also slip. Collection delays, eligibility changes, and processing lag still show up in client inboxes as "why is Search Console still amber?" The same 28-day rolling window explains part of that lag after a deploy; see why your Core Web Vitals fix is not in CrUX yet for how to phrase timelines in client reports without blaming the wrong team.

What no free Chrome UX Report dashboard replaces after retirement

Being precise about gaps prevents another bookmark rot cycle. No free Google UI reproduces every old CrUX Dashboard view in one place. CrUX Vis does not list forty client origins on one screen. PageSpeed Insights does not chart six months of TTFB without you opening each URL. Search Console does not export weekly p75 series for every template. BigQuery is powerful but not free at scale and not friendly for account managers. The History API is accurate but requires engineering time.

Third-party tools close some of those holes with paid seats, URL limits, and their own refresh schedules. None of them remove CrUX eligibility rules: low-traffic pages still lack URL-level field data, desktop and phone still split, and rolling averages still trail deploys. The workable agency pattern we see is a small stack: CrUX Vis or a field explorer for deep history on hero URLs, Search Console for SEO status, scheduled lab monitoring for portfolio regression detection, and one sentence in the report that explains collection period dates. If nobody owns the threshold on a metric and nobody acts when it breaks, it should not be on the daily list, whether the chart came from Google or a vendor.

How agencies monitor Chrome UX Report field metrics across client sites

A practical Monday workflow after the dashboard retirement:

  1. List priority origins and money URLs per client (home, pricing, signup, checkout, main templates). Match the list to URLs that actually receive Chrome traffic, not only the page engineering fixed in staging.
  2. Pin one field history view per key domain. CrUX Vis or a History API-backed explorer for quarterly reviews; note the collection period on the screenshot.
  3. Schedule lab tests on the same URLs. Use budgets so a deploy regression triggers before field data moves. Frequency guidance lives in how to schedule PageSpeed monitoring if you are standardising cadence across accounts.
  4. Pull Search Console CWV status monthly for SEO owners. Treat it as a lagging group report, not a deploy gate.
  5. Reserve BigQuery or custom API jobs for investigations (country regressions, device splits, before/after studies), not for every account manager every week.

Apogee Watcher automates steps two and three for multi-site organisations: discovery, scheduled tests, field slices when available, alerts, and client-ready exports without maintaining fifty PageSpeed Insights bookmarks. Start with a free domain check on one money URL if you want to see lab and field side by side before you add the portfolio, then expand the same URL list into budgets once the cadence feels right.

FAQ

Is the CrUX Dashboard still available?

Google deprecated the shared CrUX Dashboard and turned off the CrUX Connector at the end of November 2025. You can copy the Looker Studio template and point it at your own BigQuery project, but the hosted connector most teams used no longer updates. CrUX Vis is Google's recommended first-party replacement for historical charts.

Where do I get field TTFB now that the dashboard is gone?

Check PageSpeed Insights field data for the latest rolling TTFB when Google publishes it for your origin or URL. For history, use CrUX Vis Loading Performance charts or query the CrUX History API for weekly TTFB series. BigQuery monthly tables remain available for long-range analysis.

What is the difference between the CrUX API and the CrUX History API?

The standard CrUX API endpoint (queryRecord) returns the latest collection period, updated roughly daily. The History API endpoint (queryHistoryRecord) returns up to about 40 weekly periods, each representing the previous 28 days of experiences. Use both when you want current status plus trend context.

Can PageSpeed Insights replace the CrUX Dashboard for client reporting?

PageSpeed Insights replaces the "what is field data right now?" check for individual URLs. It does not replace multi-month trend boards or multi-site portfolios without repeated manual runs. Pair PageSpeed Insights with CrUX Vis or the History API for history, and with scheduled lab monitoring if you manage many sites.

Why is PageSpeed Insights lab data different from field data?

Lab data is a synthetic Lighthouse run under controlled conditions. Field data is the Chrome UX Report: a rolling average of real Chrome users, usually about 28 days. Both can be correct on the same URL at the same time. Use lab for same-week deploy proof; use field (and CrUX Vis or the History API for trends) for SEO and client reporting. See synthetic versus real user monitoring for how teams split those jobs after the CrUX Dashboard retirement.

Do I still need lab monitoring if I have CrUX Vis?

Yes, when you ship often or manage client sites on different schedules. Field data is always a rolling average of real Chrome users, so it lags deploys. Lab monitoring proves the same-day change on priority URLs while CrUX catches up. See synthetic versus real user monitoring for how to split responsibilities.

Open the first client domain that still has a dead CrUX Dashboard link in the wiki. Run PageSpeed Insights on the homepage and note field LCP, INP, and CLS beside this week's lab run. Open CrUX Vis on the same origin and screenshot the INP or TTFB trend with the collection dates visible. One row in your tracker is enough: latest field, lab verification, history direction. If you manage many sites and want that row filled on a schedule without manual pastes, start a free trial of Apogee Watcher or run a free PageSpeed check on the URL that pays the bills first.

References

Top comments (0)