Skip to main content
AuditJet
CrUX data, field monitoring, and beyond
</>

Treo shows you field data. AuditJet shows you the dollar figure behind it.

Treo makes Google's CrUX dataset genuinely useful. This page explains how it works, what CrUX data actually is, and where continuous monitoring picks up where field data ends.

Background

What is Treo?

Treo is a web performance analytics platform built around Google's Chrome User Experience Report, commonly abbreviated as CrUX. At its core, Treo is a well-designed interface that makes CrUX data explorable without requiring direct access to Google BigQuery, SQL knowledge, or any data engineering work.

To understand Treo, you first have to understand what CrUX is. Google collects performance metrics from real Chrome users who have opted into sharing usage statistics — people browsing the web with their own devices, on their own network connections, visiting real pages. When those users visit a website, Chrome records measurements like how long the largest image or text block took to render (Largest Contentful Paint), how responsive the page was to their first interaction (Interaction to Next Paint), and whether the page layout shifted unexpectedly as it loaded (Cumulative Layout Shift). This aggregated, anonymized dataset is what Google publishes as CrUX.

CrUX is not a tool Google built for developers — it is a byproduct of Chrome's telemetry program. But it became strategically important in May 2021 when Google began using Core Web Vitals as a ranking signal. That meant the CrUX dataset was no longer just interesting analytical data; it was literally the numbers Google was feeding into its search ranking algorithm. If you wanted to know how Google saw your site's performance, CrUX was the answer.

The problem was access. The full CrUX dataset lives in BigQuery. Querying it requires a Google Cloud account, SQL knowledge, and an understanding of how the dataset is structured — a significant barrier for developers and SEOs who just want to know whether their LCP improved after last month's deploy. Treo was built to close that gap. It ingests CrUX data on Google's release schedule and presents it through charts and drill-downs that anyone can use.

Treo's target audience is developers, SEOs, and product teams who care about Core Web Vitals trends over time. It occupies a distinctive market position: it is essentially a free analytics layer on top of public Google data, which means the information it surfaces is identical to what Google itself is using to evaluate your site. That is a genuinely valuable property. Many commercial performance tools show you synthetic data that may not match what Google sees. Treo shows you exactly Google's view.

Treo offers a free tier with meaningful functionality — enough to explore CrUX data for most sites without paying anything. Paid plans unlock features like API access, bulk URL analysis, and additional historical depth. This pricing model reflects the underlying economics: the data itself is free (it's public), so Treo monetizes the workflow built around it.

The dataset

How CrUX Works

CrUX is more nuanced than it appears at first glance. To use it well — and to understand Treo's outputs — you need to understand several properties of the dataset that are not always obvious.

Field data vs. lab data

Performance measurement divides into two fundamental categories. Field data is collected from real users visiting your site with real devices and real network connections. It captures the genuine distribution of experience across your audience — including the person on a five-year-old Android phone on a congested 3G connection in rural Indonesia who is trying to load your homepage. Lab data is collected by running a simulated page load in a controlled environment, using throttled network speeds and a consistent virtual device profile. Lighthouse, Google's open-source audit tool, is the most widely used source of lab data.

Neither is better. They answer different questions. Lab data is reproducible: run the same test twice and you get comparable results, which makes it useful for regression detection after a deploy. Field data is realistic: it reflects what users actually experience, including edge cases and conditions no lab can simulate. CrUX — and by extension Treo — is field data. That's a strength and a constraint simultaneously.

Origin-level vs. URL-level data

CrUX reports at two granularities. Origin-level data aggregates measurements from all pages across your entire domain into a single set of scores. This is available for most sites with meaningful traffic and gives you a bird's-eye view of overall performance. URL-level data reports on individual pages separately, letting you see that your homepage has excellent LCP while your product listing pages are struggling. URL-level data requires a minimum traffic threshold — Google's guidelines indicate roughly 1,000 pageviews within a 28-day window. Pages below that threshold simply do not appear in URL-level CrUX reports. For many sites, this means the vast majority of their URLs have no URL-level data at all, leaving origin-level aggregates as the only available view.

The 75th percentile

CrUX does not report average scores. It reports at the 75th percentile (p75). A p75 LCP of 3.2 seconds means that 75% of user sessions recorded an LCP of 3.2 seconds or faster — and therefore 25% of sessions were slower than 3.2 seconds. Google's "Good" threshold for LCP is 2.5 seconds at the 75th percentile. This design choice means the metric is robust to outliers but also that a significant minority of real users may be having a substantially worse experience than the headline number suggests. When you see a "Good" CrUX score, it does not mean every user has a good experience; it means most do.

The rolling 28-day window

CrUX aggregates data over a rolling 28-day window and is updated once per month. This means a deploy you shipped today will not appear in CrUX data for up to four weeks — and because the window continues to include pre-fix sessions, partial reflection may take longer still. For understanding long-term trends, this is acceptable. For detecting whether last Tuesday's release introduced a regression, it is completely unworkable. This is the most significant structural constraint of any CrUX-based tool.

Chrome telemetry only

CrUX data comes exclusively from Chrome users who have opted into usage statistics on non-incognito sessions. Firefox users, Safari users, and all mobile browsers except Chrome for Android do not contribute to the dataset. Depending on your audience, this may mean CrUX underrepresents a significant portion of your real traffic. Sites with a high proportion of iOS users (who use Safari by default) will find that CrUX does not capture that segment's experience at all. This is a structural limitation of Google's data collection approach, not something any tool built on CrUX can work around.

BigQuery and the Treo abstraction

Google makes the raw CrUX dataset available in BigQuery under an open license. Anyone can query it — but doing so meaningfully requires SQL proficiency, an understanding of the schema, and a Google Cloud account. Treo's core engineering work is building and maintaining the pipeline that ingests this data and the interface that makes it navigable. When you use Treo, you are interacting with the same underlying data you would get from a BigQuery query, just without needing to write one.

Product features

Key Features of Treo

Treo builds a useful workflow on top of the CrUX dataset. Its features are a direct reflection of what CrUX makes possible and what it does not.

Historical trend charts

Treo's most compelling feature is its historical timeline. Because CrUX has been collecting data since 2017, Treo can show you how your Core Web Vitals scores have evolved over years — not just months. This makes it possible to correlate performance changes with site redesigns, technology migrations, or content updates that happened long before you had any other monitoring in place. For sites trying to understand why their scores are where they are today, the historical depth is uniquely valuable.

URL-level drill-down

Where most people encounter CrUX first is through origin-level data in PageSpeed Insights. Treo extends this by exposing URL-level CrUX data for individual pages, letting you compare how different sections of your site perform in the field. A product page may have significantly worse LCP than the homepage due to hero image handling or third-party scripts. URL-level data surfaces those differences without requiring you to run a separate test on each page.

Technology segment filtering

CrUX records metadata about the sessions it collects, including device type (desktop, phone, tablet), connection type (4G, 3G, WiFi), and effective connection type. Treo exposes these as filters. If you want to know how mobile users on 4G connections specifically experienced your site last month — rather than the blended origin average — you can isolate that segment. This is particularly useful when debugging why your mobile CWV scores diverge significantly from desktop.

Competitor CrUX comparison

Because CrUX is a public dataset, Treo can show you field data for any site in the dataset — not just your own. This means you can compare your origin-level CrUX scores against competitors using the same methodology and the same data source. Both scores reflect real user experiences as measured by Chrome, making the comparison methodologically clean in a way that synthetic competitor benchmarks often are not.

API access (paid)

Treo's paid tiers include programmatic API access to the CrUX data it surfaces. This is useful for teams that want to pull CrUX trends into their own dashboards, correlate performance data with business metrics in a data warehouse, or automate competitive monitoring at scale. The API returns the same data as the Treo interface — it is a convenience and integration tool, not an additional data source.

Honest assessment

Strengths and Limitations

No tool is right for every job. Understanding what Treo does well — and where its constraints lie — is the only way to evaluate whether it belongs in your workflow.

Strengths

  • Google's actual view of your site

    CrUX is the data that influences search rankings. No other source gives you a more authoritative read on how Google perceives your performance. If your goal is SEO alignment, this matters more than any synthetic score.

  • Deep historical record

    CrUX data goes back to 2017. Very few performance tools can show you how a site was performing five years ago. For post-mortems, trend analysis, or understanding inherited technical debt, this historical depth is difficult to replicate.

  • Genuinely useful free tier

    The free tier gives meaningful access to CrUX data for most use cases. Teams with limited budgets can get real value without any payment commitment.

  • Zero implementation required

    There is no script to install, no DNS change, no tracking pixel. Treo reads public data. You can check any site in the CrUX dataset — including sites you do not own — without touching a single line of code.

  • Trends you could not otherwise see

    Without CrUX, understanding how millions of real-world Chrome users have experienced your site over time would require your own massive RUM infrastructure. CrUX provides this at no cost.

Limitations

  • 28-day lag makes regression detection impossible

    If a deploy breaks your LCP on Tuesday, CrUX will not reflect that change in Treo for up to four weeks. By the time the data shows a problem, the damage to real users — and potentially to rankings — has already been done.

  • Low-traffic pages have no URL-level data

    Pages receiving fewer than roughly 1,000 visits per 28-day window do not appear in URL-level CrUX reports. For many sites, this covers the majority of their URLs. You can see origin-level averages but cannot diagnose which specific pages are pulling scores down.

  • No alerting or automated monitoring

    Treo is a passive tool. It shows you what happened; it does not tell you when something changes. There are no alerts, no regression notifications, and no way to be informed proactively when a score drops.

  • No synthetic monitoring

    CrUX-based tools cannot test changes before they reach real users. You cannot validate a performance optimization in a staging environment and see it reflected in Treo. Synthetic monitoring and CrUX serve fundamentally different purposes.

  • No fix guidance

    Treo shows you scores and trends. It does not explain what is causing a poor score, which resources are responsible, or what code changes would address the problem. You need a separate diagnostic tool to move from awareness to action.

  • Chrome-only dataset

    Safari, Firefox, and non-Chrome mobile browsers contribute no data to CrUX. On sites with a significant iOS audience, a meaningful share of user experience goes unmeasured.

Direct comparison

AuditJet vs Treo

The most honest framing here is that Treo and AuditJet are complementary rather than competing tools. They answer different questions at different time horizons. The decision of which to use — or whether to use both — depends on what you are trying to know.

Treo answers: "How have real Chrome users experienced my site over the last 28 days, and how has that trended over time?" This is a historical, backward-looking, field-data question. It tells you the state of things as Google sees them.

AuditJet answers: "What is my site's performance right now, will it regress after my next deploy, and what does that cost in revenue?" This is a forward-looking, operational question. It is about maintaining quality as your site changes.

The lab + field combination

AuditJet runs Lighthouse-based synthetic audits on a scheduled basis. This lab data is reproducible and reacts immediately to changes — a regression shows up in the next scheduled run, typically within minutes of a deploy. AuditJet also collects its own real-user monitoring data via a sub-1KB script, giving you field data that is specific to your visitors, updates in real time, and captures non-Chrome users that CrUX ignores.

The combination of lab and field data matters because each plugs the other's gaps. Synthetic monitoring catches regressions immediately but can miss real-world variation in device and network conditions. RUM captures that variation but has no equivalent in a staging environment. Running both gives you the fastest possible feedback loop and the most realistic view of actual user experience.

Regression detection speed

This is where the tools diverge most sharply in practical value for engineering teams. AuditJet detects performance regressions within minutes of a deploy and can alert your team via Slack, email, or webhook before the change has propagated broadly. CrUX takes up to four weeks to reflect the same change. For teams shipping code daily, a four-week feedback loop on performance is not a monitoring strategy; it is a lagging indicator that tells you about problems that have already cost you conversions.

What AuditJet adds

Beyond monitoring and alerting, AuditJet layers three capabilities that have no equivalent in CrUX-based tools. AI Fix Blueprints translate Lighthouse audit findings into code-level guidance — specific changes to make in specific files, not generic recommendations. Revenue impact modeling connects performance scores to estimated conversion impact using your site's own traffic data, giving engineering teams the business context needed to prioritize fixes against other work. Competitor monitoring runs Lighthouse against competitor URLs on the same schedule as your own site, so you can see relative performance shifts without relying on public CrUX data that may be weeks behind.

Using both

Many mature performance teams use Treo for what it is genuinely best at — understanding long-term CrUX trends, tracking Google's historical view of their field performance, and doing strategic analysis that benefits from multi-year data — while using AuditJet for continuous monitoring, regression alerting, and the full workflow from detection to remediation. The tools are not redundant. They operate at different time scales and answer different questions.

CapabilityAuditJetTreo
Real-user field dataRUM via sub-1KB script — your own visitors, real time.CrUX data only — Chrome users globally, 28-day lag.
Synthetic monitoringHourly Lighthouse scans with regression alerts.Not available.
Regression detection speedMinutes after a deploy.Up to 4 weeks (CrUX update cycle).
Historical CrUX trendsAvailable via integrated CrUX data.Core feature — data back to 2017.
Revenue impact modelingConnects CWV scores to estimated conversion risk.Not available.
AI Fix BlueprintsCode-level fix guidance per issue (Watchdog+).Not available.
Competitor benchmarkingScan competitor pages on the same schedule as your own.Origin-level CrUX comparison only.
Alerts & notificationsSlack, email, and webhook alerts on regression.Not available.
Implementation requiredLightweight script for RUM; zero setup for synthetic.None — reads public data.
Free tierFree single-URL audit; paid plans from $49/mo.Free tier with meaningful CrUX access.

Decision guide

Who should use each?

The right tool depends on the question you are trying to answer. Here is a direct breakdown.

Use Treo if…

  • You want free access to Google's official CrUX field data with no setup.

  • You are doing historical research — looking at how scores have changed over months or years.

  • You want to understand your long-term Core Web Vitals trend as Google sees it.

  • You are comparing your origin-level performance against competitors using the same public dataset.

  • You do not need real-time alerting and are comfortable checking data manually.

  • Your team does not have the budget for a monitoring platform but still needs CWV visibility.

  • You want to audit a site you do not own without installing any code.

Use AuditJet if…

  • You need to know within minutes — not weeks — when a deploy degrades performance.

  • You want fix guidance, not just scores: specific code changes that address specific issues.

  • You need revenue impact context to prioritize performance work against other engineering investments.

  • You are managing multiple sites and need centralized monitoring with alerting.

  • You want synthetic monitoring on a staging URL before changes reach production.

  • You need RUM data from your own visitors, including non-Chrome users CrUX ignores.

  • Your team needs to monitor competitor pages on-demand, not just compare public CrUX averages.

Frequently asked questions

What is CrUX data?

CrUX stands for Chrome User Experience Report. It is a public dataset maintained by Google that aggregates real-world performance metrics — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and others — from Chrome users who have opted in to sharing usage statistics. The data reflects genuine user experiences across different devices, network conditions, and geographic locations, and it is the field data that Google uses when evaluating sites for search ranking purposes.

Why is there no data for some of my pages in Treo?

CrUX URL-level data requires a minimum traffic threshold of approximately 1,000 pageviews within a 28-day period before Google will surface data for that specific URL. Pages with lower traffic simply do not appear in URL-level CrUX reports. Origin-level data (aggregated across your entire domain) has a lower threshold and is available for most sites, but it cannot tell you how individual low-traffic pages are performing.

How is AuditJet different from Treo?

Treo is a read-only viewer for Google's CrUX field data, showing you how real Chrome users have experienced your site over the past 28-day rolling window. AuditJet is an active monitoring platform: it runs scheduled Lighthouse audits, collects real-user metrics from your own visitors via a lightweight script, alerts you within minutes when a score regresses, models the revenue impact of performance changes, and provides AI-generated code-level fix guidance. The two tools answer different questions and many teams use both.

Can I use both Treo and AuditJet together?

Yes, and many teams do. Treo is excellent for understanding long-term CrUX trends and Google's historical view of your site's field performance — data that goes back to 2017. AuditJet handles everything that needs to happen in real time: detecting regressions within minutes of a deploy, alerting your team, estimating revenue impact, and guiding engineers through the fix. The two tools are complementary, not mutually exclusive.

Does Treo have alerting?

Treo does not offer automated alerting. It is a passive analytics tool — you log in, explore the charts, and draw your own conclusions. If a CrUX score worsens between monthly updates, Treo will show you the change the next time you check, but it will not proactively notify you. AuditJet sends Slack messages, emails, or webhook payloads within minutes of detecting a regression.

How long does it take for CrUX data to reflect a change I made?

CrUX uses a rolling 28-day aggregation window and is updated once per month (roughly). A performance improvement you deploy today will not be fully reflected in CrUX data for up to four weeks — and partial reflection may take even longer, since the window continues to include pre-fix sessions. This lag is inherent to the dataset, not a Treo limitation. It makes CrUX fundamentally unsuitable for regression detection or validating the immediate impact of a deploy.

What is the difference between field data and lab data?

Field data (also called real-user monitoring or RUM) is collected from real visitors using real devices on real network connections. It captures the full distribution of user experience. Lab data is collected by running a simulated page load in a controlled test environment — Lighthouse is the most common example — using fixed network throttling and a consistent virtual device. Neither is better; they answer different questions. Lab data is reproducible and useful for regression detection after a deploy. Field data tells you how actual users, including those on slow mobile connections in distant geographies, are experiencing your site.

Does AuditJet use CrUX data?

AuditJet collects its own real-user data via a sub-1KB JavaScript snippet that captures Core Web Vitals from your actual visitors — not from the CrUX dataset. This means your data is specific to your visitors, not aggregated from all Chrome users globally, and it is available in real time rather than on a 28-day rolling window. AuditJet also runs Lighthouse-based synthetic audits on a scheduled basis for immediate regression detection.

From field data awareness to revenue-safe performance.

AuditJet adds continuous monitoring, regression alerts, AI fix guidance, and revenue context on top of the field data story that CrUX starts.

Website Performance Monitoring & Core Web Vitals Tracking | AuditJet