Coder Legion - Recent posts tagged crux

Partial Page Loads in CrUX: What Field Data Includes (and Excludes)

Sat, 17 Oct 2026 16:13:27 +0000

A Lighthouse or PageSpeed Insights laboratory run is designed to finish. The synthetic client navigates, waits for paints, and reports Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift for that controlled pass. Chrome User Experience Report (CrUX) field percentiles are not the same experiment run later. They aggregate many real Chrome experiences, including visits that never complete a “full page load” story the way a lab profile does.

That gap is what people mean when they ask how CrUX handles partial page loads or partial sessions. Lab green and field amber on the same URL often coexist because the field bucket mixes completed navigations with abandoned tabs, background starts, back/forward cache restores, and (for many SPAs until soft-navigation metrics are available in reporting tools) long lives on a single document URL. What follows maps what field data includes and excludes, how that differs from Lighthouse, and what to put in a client report when the clocks disagree.

Keep When to Use Synthetic vs Real User Monitoring open for the broader lab-versus-field split, and When PageSpeed Insights Shows No CLS or INP for Your URL when metric rows are missing while other field data exists. Thresholds and “good” ranges sit in What Are Core Web Vitals? A Practical Guide for 2026.

What “partial page loads” means in CrUX field data

CrUX does not sell a public metric literally named “partial session.” In practice the phrase covers real experiences that diverge from a completed, foreground, full-document navigation of the kind Lighthouse scripts. Chrome’s CrUX methodology starts from eligible user experiences, then aggregates them into page-level and origin-level distributions. An “experience” is the metrics collected during a page view, not a synthetic end-to-end script that always waits for a quiet network.

Agencies usually meet four shapes of “partial” that get blurred in one client chat:

Abandoned or interrupted loads. The user navigates away, closes the tab, or loses connectivity before the lab-style quiet window, yet field may still record early paints or interactions that did fire.
Visibility and background starts. Pages opened in a background tab, or hidden before LCP settles, follow different LCP rules than a focused lab run.
Non-navigate restorations. Back/forward cache and prerender activations are real visits for users, but not every timer (especially Time to First Byte) is collected the same way as a cold document load.
SPA soft navigations. Route changes that look like new pages to users may still be attributed to the initial document URL in classic CrUX Core Web Vitals until soft-navigation metrics are used.

Those shapes are why a retainer that only re-runs PageSpeed Insights after a deploy can look fixed in the lab while Search Console or the CrUX panel stays amber. The field distribution is answering a different question: what happened across many real visits, including ones that never matched the synthetic path. Lab colour and field colour are both honest answers; they are just answering different populations.

What CrUX includes that a Lighthouse run never sees

Field data is population data. Origin-level CrUX includes eligible experiences across the origin’s pages (subject to discoverability and popularity rules). Page-level CrUX needs enough samples for that URL. Neither side downsamples for convenience: Google has stated that aggregates use the eligible experiences that arrive, weighted by how often those experiences happen, not by how tidy they look in a waterfall.

Lighthouse does not visit the site as a busy shopper who opens five tabs, restores from history, or arrives via a soft navigation after checkout. It runs one (or a few) controlled profiles, which is a strength for regression testing: comparable conditions, repeatable budgets, dated history. It is a weakness if someone treats the lab pass as proof that field percentiles must move this week. PageSpeed Insights vs Automated Monitoring covers when scheduled lab history is still the accountable layer; partial-load mismatch is one reason field can lag or disagree even when lab looks clean.

CrUX also folds some complexity into the top-level page. Content in iframes is not reported as a separate CrUX URL; it can still move metrics on the parent page the user sees. Agencies debugging “our LCP is an embedded player” need that distinction labelled in the report, not buried in a screenshot caption.

What CrUX excludes (or stops measuring) mid-experience

Background and visibility. Not every browser event becomes a Core Web Vitals sample the way teams expect. Google tools that measure LCP do not treat a page loaded entirely in the background as a normal user-perceived load. The Largest Contentful Paint API can still emit entries in awkward visibility cases; the metric used for CrUX and related tooling ignores experiences where LCP is not a fair foreground story. A lab run that always starts focused will never reproduce that filter.

Interaction cut-off for LCP candidates. Once the user taps, scrolls, or presses a key, browsers stop treating later paints as new LCP candidates for analysis purposes. Real sessions often interact early, so the field stop can arrive sooner than in a synthetic run that sits idle until the largest element paints. That alone can separate a calm lab LCP from a noisier field distribution.

Timers that skip some navigation types. CrUX navigation types show how often visits are ordinary navigates, cached document loads, reloads, back/forward, bfcache restores, or prerenders. Core Web Vitals such as LCP are measured for bfcache restores in ways that match user perception of a new visit. Time to First Byte in CrUX is collected on full page loads, not on every restore path, so TTFB sample sizes and stories can diverge from LCP on the same origin. Treating every field metric as if it sampled the same set of navigations is a reporting error.

Eligibility gaps. Origins or URLs with no CrUX data yet are a different problem: not enough eligible samples or discoverability failures. That is covered in Why CrUX Has No Data for Your Site. Partial-load nuance only applies once field rows exist.

Lab vs field Core Web Vitals when loads are incomplete

Use an explicit comparison when a client asks why the lab card is green and the field card is not. The table below is the pairing we keep in decks so nobody treats PageSpeed Insights lab colour as a CrUX forecast. Each row answers one question clients usually ask in the same meeting.

Question	Lab (Lighthouse / PageSpeed Insights lab)	Field (CrUX)
What is measured?	One controlled navigation under a fixed profile	Many real Chrome experiences over a rolling window
Does the run always “finish”?	Yes, by design	No; users abandon, hide tabs, or restore from cache
Device and network mix?	Emulated / fixed	Real devices and networks in the eligible sample
SPA route changes?	Usually one document load per run	Historically attributed to the initial URL; experimental soft-navigation metrics arriving in CrUX
Best use	Regression after deploy; budgets you can retest tomorrow	Ranking-facing experience; catch journeys lab never walked

Lab versus field Core Web Vitals disagreements are often population disagreements, not “PageSpeed Insights is broken,” so say that plainly and then show which URLs you tested in the lab and which templates dominate traffic in analytics or Search Console groups. Aligning synthetic coverage with revenue and conversion paths does not force CrUX to match overnight. It does stop the team from optimising a quiet brochure URL while field pain sits on checkout.

When field categories move slowly after a fix, the rolling window and pipeline lag matter too. Why Your Core Web Vitals Fix Is Not in CrUX Yet covers the 28-day collection habit. Partial-load mix is an additional reason a single green lab screenshot is weak evidence for “field will be green by Friday.”

CrUX vs Lighthouse: same URL, different experience set

CrUX versus Lighthouse comparisons fail when people assume both tools sample the same visits. Lighthouse answers: under these conditions, what did this URL do? CrUX answers: among eligible Chrome users on this page or origin, what did the distribution of experiences look like?

Lighthouse will not invent a bfcache restore fraction, and CrUX will not pause the internet so every shopper waits for your hero image the way a lab profile does. Both can be correct. Client decks that print one Performance score next to one field category without labels invite false conclusions, so prefer two short labelled lines: lab result with date, strategy, and URL; field result with form factor and the collection window the tool shows.

Scheduled lab history still earns its keep, because partial sessions make field distributions harder to debug from a single paste. Agencies need a trail of comparable synthetic runs on the templates that matter. That is monitoring, not a substitute for CrUX.

Soft navigations and SPA routes: historical gap and October 2026 experiments

For years, SPA architectures complicated Core Web Vitals because soft navigations looked like new pages to users while platform APIs still treated the experience as one document life. CrUX methodology documents that limitation and points to How SPA architectures affect Core Web Vitals on web.dev. In that model, route transitions did not reset classic Core Web Vitals the way a full navigation would, so field scores could look harsh on long-lived documents or oddly attributed to landing URLs.

As of October 2026, Chrome has started publishing experimental CrUX metrics that include soft navigations, with an aim to graduate them later. Tooling catch-up will take time. Until your reporting stack shows those experimental series clearly, keep two habits: (1) do not pretend classic CrUX already splits every SPA route as its own page URL; (2) use first-party RUM or the newer soft-navigation APIs when you need route-level debugging ahead of CrUX tool support. Label experimental field rows as experimental in client language so nobody treats a preview series as Search Console fact.

What agencies should report when lab is green and field is amber

What we measured in the lab. Use a short script so the conversation stays honest across accounts. Dated Lighthouse or PageSpeed Insights lab runs on [list URLs], mobile and desktop as separate rows, under a fixed profile. Those runs completed by design, which is useful for regression and useless as a CrUX forecast on its own.

What field data is saying. CrUX (via PageSpeed Insights, Search Console, or the API) reflects a mix of real experiences, including visits that abandon early, change visibility, restore from bfcache, or stay on long SPA documents. Field amber does not mean the lab tool lied. It means the population of experiences is wider than one synthetic pass.

What we are not claiming. We are not saying the next lab refresh will force field percentiles this week. Collection windows and experience mix both move slowly relative to a deploy day. Partial loads are part of that mix rather than a bug in the PDF export.

What we will do next. Keep synthetic budgets on the journey URLs that match analytics and revenue, and re-check CrUX on a fixed schedule. If SPA routes dominate the product, add route-aware real-user monitoring or soft-navigation debugging rather than only re-running homepage Lighthouse. That script pairs with synthetic versus real-user roles in the monitoring guide linked earlier, and partial page loads are one more reason to layer clocks instead of picking a favourite colour on a single card.

FAQ

Do CrUX percentiles include users who leave before the page finishes loading?
Field data includes eligible experiences that occur in real browsing, not only visits that reach a lab-style quiet network. Early abandons can still contribute paints or interactions that fired. That is one reason distributions differ from a completed Lighthouse pass.

Why is lab LCP good when field LCP is poor?
Common causes include different devices and networks, background or visibility filters, interaction timing, navigation-type mix (including bfcache), SPA attribution, and URL selection that does not match traffic. Treat the disagreement as a population problem first. Then debug the templates that dominate real visits, not only the quiet URL that scored well in the lab.

Does bfcache count as a page load in CrUX?
Users experience bfcache restores as navigations. CrUX reports navigation-type fractions and measures Core Web Vitals for restores in defined ways. Some supporting timers such as TTFB are tied to full page loads, so do not assume every metric samples the same navigations.

Are SPA soft navigations in CrUX yet?
Historically, soft navigations were not separate classic Core Web Vitals page views in CrUX. Experimental soft-navigation metrics began appearing in CrUX around October 2026, but tooling catch-up varies. Confirm what your dashboard actually plots before you brief a client.

Should we stop lab testing and trust only CrUX?
No. Lab remains the regression and budget layer you can re-run on demand, while CrUX remains the public field distribution. Agencies need both labelled, plus journey-aligned URL lists.

CTA

When lab and field disagree, name the experience set: completed synthetic runs versus CrUX’s mix of partial, restored, and long-lived visits. Align scheduled lab checks with the URLs users actually travel, keep budgets on those templates, and re-read field categories on a fixed calendar rather than after every deploy. For eligibility gaps with no field rows at all, use the CrUX no-data guide. For turning one-off PageSpeed Insights into a schedule across clients, start with Apogee Watcher or run a public check from the homepage tools.

References

CrUX methodology (Chrome for Developers)
CrUX metrics (Chrome for Developers)
Navigation types now available in CrUX (Chrome for Developers)
Largest Contentful Paint (LCP) (web.dev)
How SPA architectures affect Core Web Vitals (web.dev)
Chrome UX Report discussions (Chromium; partial load sessions thread, May 2026)
When to Use Synthetic vs Real User Monitoring (Apogee Watcher)
When PageSpeed Insights Shows No CLS or INP for Your URL (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)
What Are Core Web Vitals? A Practical Guide for 2026 (Apogee Watcher)
Why CrUX Has No Data for Your Site (Apogee Watcher)
Why Your Core Web Vitals Fix Is Not in CrUX Yet (Apogee Watcher)

Originally published on Apogee Watcher.

Why CrUX Has No Data for Your Site

Wed, 14 Oct 2026 06:57:44 +0000

“No data” in the Chrome User Experience Report (CrUX) is not a single bug. It is a set of eligibility gates. Google only publishes field percentiles when enough opted-in Chrome sessions meet privacy and quality rules for that origin or URL. PageSpeed Insights and Search Console inherit those gaps. Lab scores from Lighthouse can still look complete on the same screen, which is why teams often treat a blank field block as a tool failure instead of an eligibility outcome.

The sections below walk those gates for client sites: when an origin is missing from CrUX entirely, when a URL is thin while the origin still has data, what to say to the client, and what to monitor until field samples exist. Keep When PageSpeed Insights Shows No CLS or INP for Your URL open for metric-level gaps on a URL that may already show other field rows. For how lab and field clocks differ, use What Are Core Web Vitals? A Practical Guide for 2026 and When to Use Synthetic vs Real User Monitoring as context.

What “no CrUX data” means on a site

CrUX is Google’s public field dataset for how real Chrome users experience popular destinations. It is also the field source behind PageSpeed Insights “Discover what your real users are experiencing” and related Search Console Core Web Vitals views. When CrUX has no data for a query, tools typically show a missing field section, an API NOT_FOUND style response, or a message that Chrome UX Report data was not found. That is different from a red or amber field category. There is no percentile to classify yet.

Agencies usually meet three patterns of “no data” that get mixed together in client chat: (1) origin absent (https://www.client.com or the wrong scheme/host variant is not in the dataset at all); (2) URL thin, origin present (the homepage or a landing path has no URL-level field rows, while origin-level field data still exists); (3) metric missing (some field metrics appear and others do not, for example LCP present and INP absent). Pattern (3) is covered in the PageSpeed Insights “no CLS or INP” guide linked above. What follows focuses on (1) and the client conversation around (2). The practical question is not whether PageSpeed Insights is broken; it is which eligibility gate failed, and what you measure until field data exists. Naming the gate early stops the team from chasing Lighthouse scores that never create field rows.

Chrome UX Report eligibility: user, origin, and page

Google’s CrUX methodology describes three layers that must line up before an experience counts toward page-level field data in PageSpeed Insights and the CrUX API: the user, the origin, and the page. Experiences that meet user and origin rules but not page rules can still feed origin-level data. Pages and origins appear and disappear automatically as eligibility changes. You cannot manually submit a site for inclusion.

User eligibility means the visit came from a Chrome user whose settings allow contribution to the statistics dataset. Not every browser, privacy mode, or visitor is included. CrUX is a sample, not a full count of all traffic in analytics.

Origin eligibility needs two properties: the origin must be publicly discoverable, and it must be sufficiently popular. Discoverability is about whether the root of the origin can be treated as a public page (indexing and successful HTTP status on the root matter; blocked or failing roots are a common trap). Popularity means enough eligible experiences across the origin’s pages for Google to publish anonymised distributions. The exact threshold is not disclosed.

Page eligibility adds that the specific URL must also be popular enough for URL-level distributions. A thin blog post or campaign landing page can lack URL-level CrUX while the origin still has field data. That is expected on long-tail templates.

HTTP versus HTTPS and www versus apex are different origins. So are subdomains. https://shop.example.com does not inherit CrUX from https://www.example.com. When someone says “the client site has no CrUX data,” name the origin string you queried, including scheme and host.

Why an origin is missing from CrUX entirely

Wrong origin string. When tools say the origin is not in the Chrome UX Report, check the origin string before you promise a timeline for field data, then move on to discoverability and sample size. Teams often query http://, omit or add www, or paste a path when the API expects an origin. The CrUX API docs recommend comparing the navigable final URL after redirects with the origin you requested. A 404-style “chrome ux report data not found” response is common when the string is simply wrong.

Root not publicly discoverable. If the root redirects in a way that systems treat as undiscoverable, or if the root fails indexing / HTTP status checks, the origin can drop out even when inner URLs get traffic. Chromium discussion threads have long noted redirect-heavy roots as a reason PageSpeed Insights may show URL-level data after following a redirect while origin-level data is missing. Fix discoverability before you blame sample size alone.

Not enough eligible Chrome traffic. Small sites, brand-new launches, sites that behave like private apps, and niches with little opted-in Chrome usage may never meet popularity. Google does not publish the cut-off. In our experience, waiting a few more PageSpeed Insights refreshes does not create an origin that is structurally ineligible.

Not a ranking penalty by itself. Missing CrUX data is not the same as Search saying the site is slow. It means Google does not have enough public field evidence to publish Core Web Vitals percentiles for that origin or URL slice. Search Console may still show limited or grouped signals. Do not invent a field fail from a blank PageSpeed Insights field block.

URL-level gaps when the origin still has field data

If origin-level field data exists but the client’s main URL shows no URL-level CrUX, you are usually looking at popularity at the page layer, not a dead origin. Homepage and key templates often qualify first; checkout steps, locale paths, and campaign URLs lag. PageSpeed Insights may still show origin-level field categories while the URL field rows are empty. Label that clearly in reports so nobody presents a Core Web Vitals pass for a thin URL using only origin-level fallback.

When the gap is “this metric is missing but others appear,” use the dedicated guide for missing CLS or INP field rows. When the gap is “this URL has no field block but the origin does,” keep synthetic monitoring on that URL and wait for samples. Do not treat origin green as URL green in a client report; say which level the numbers come from.

What to tell the client when field data is unavailable

What we know. Use a short script so the conversation stays honest across accounts. CrUX has no (or incomplete) field data for [origin or URL] right now. That usually means eligibility: discoverability, traffic sample size, or the wrong host/scheme, not a broken lab test. We should confirm the origin string before we talk about traffic volume.

What we do not claim. We are not saying the page passes or fails Core Web Vitals in the field. We do not have the percentiles yet. Lab scores alone cannot fill that gap in a report to the client.

What we will watch instead. Scheduled lab tests on the homepage and other priority URLs (mobile and desktop as separate rows), with budgets and alerts, until URL-level or origin-level field data appears. We will re-check CrUX on a fixed schedule and say when field rows show up. That gives the retainer a measurable trail while field data is empty.

What we need from them. Confirm the public origin (HTTPS, www or apex), that the root is indexable, and which URLs matter for the retainer. If the root redirects oddly or blocks indexing, that is an eligibility fix, not a Lighthouse tweak. Without a correct public root, more lab runs will not create CrUX rows. Pair that script with PageSpeed Insights vs Automated Monitoring: one-off PageSpeed Insights explains a moment, and scheduled runs explain change over time when field data cannot.

What to monitor instead: synthetic budgets on priority URLs

Until field data is available, synthetic (lab) monitoring is what you can report against week to week. Pick a small URL set: homepage, primary landing templates, and checkout or lead paths. Run the same lab profile on a schedule, store history, and alert when LCP, CLS, or related lab metrics cross a budget. How to Schedule PageSpeed Monitoring covers frequency and priority across a portfolio. Synthetic versus real-user roles are spelled out in the synthetic vs RUM guide linked earlier.

Lab data will not replace field eligibility, but it stops the retainer from depending on a blank CrUX panel. When origin or URL field data appears, add it to the same report without throwing away the lab history that covered the gap. In Apogee Watcher, scheduled PageSpeed Insights–backed checks keep that lab trail across client sites while CrUX field rows are absent or partial.

FAQ

Does “CrUX no data” mean the site is slow?
No. It means Google does not have enough eligible Chrome samples (or the origin is not publicly discoverable in the way CrUX requires) to publish field percentiles. Lab tools can still diagnose the template while you wait for eligibility.

Can we force a site into the Chrome UX Report?
No. Inclusion is automatic when eligibility is met. You cannot manually submit an origin. Fix discoverability and grow real Chrome traffic, then re-check later.

Why does PageSpeed Insights show lab scores but no field section?
Lab data comes from Lighthouse on demand. Field data comes from CrUX only when eligibility passes. Both can appear on one PageSpeed Insights page, and either side can be missing independently.

Are subdomains included with the main domain?
No. Each origin is separate. https://blog.example.com needs its own eligibility. Query the origin the client actually cares about, including scheme and host.

How long until field data appears after a launch?
There is no public SLA. CrUX uses a rolling collection window and popularity thresholds. New or low-traffic origins can stay empty for a long time. Plan synthetic monitoring from day one rather than waiting for CrUX before you set budgets.

CTA

If a client site shows CrUX no data, name the origin, check discoverability and host/scheme, and say clearly that field percentiles are unavailable. Then put synthetic budgets on the priority URLs so the retainer still has numbers to report on a schedule. For metric-level PageSpeed Insights gaps, use the no CLS/INP guide. For turning one-off PageSpeed Insights into a schedule across many clients, start with Apogee Watcher or run a check on a public URL from the homepage tools.

References

CrUX methodology (Chrome for Developers)
Overview of CrUX (Chrome for Developers)
How to use the CrUX API (Chrome for Developers)
When PageSpeed Insights Shows No CLS or INP for Your URL (Apogee Watcher)
What Are Core Web Vitals? A Practical Guide for 2026 (Apogee Watcher)
When to Use Synthetic vs Real User Monitoring (Apogee Watcher)
PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough (Apogee Watcher)
How to Schedule PageSpeed Monitoring: Test Frequency and Priority Across a Portfolio (Apogee Watcher)

Originally published on Apogee Watcher.

Core Web Vitals Benchmarks for Shopify Stores (2026 Data)

Wed, 16 Sep 2026 08:04:00 +0000

Shopify's own theme performance table still shows median pass rates in the 80–97% range for LCP, INP, CLS, and “all Core Web Vitals.” Open a multi-page Lighthouse sample on a real storefront and the story often flips: mobile Performance scores cluster near 50, lab LCP averages stretch well past Google's 2.5 s “good” line, and unused JavaScript shows up on almost every domain. Both views can be true. Theme-level CrUX aggregates describe shops that look like a given theme under field conditions. Portfolio monitoring needs URL-level and multi-page evidence, because apps, media, and collection templates decide what shoppers feel.

What follows separates those clocks, publishes a reproducible sample from Shopify leads we analyse in Apogee Watcher, and points at the tuning work that actually moves scores. For store-level fixes after you read the numbers, pair this with Shopify Speed Optimization: Core Web Vitals Guide for E-Commerce.

What counts as a reliable Shopify Core Web Vitals benchmark in 2026

For Core Web Vitals, the strongest public field source remains the Chrome UX Report (CrUX). Google's methodology is clear about inclusion: pages and origins must be publicly discoverable and popular enough, data comes from eligible Chrome users, and thresholds are read at the 75th percentile over a rolling window. That is why Search Console and the field section of PageSpeed Insights matter for ranking and real-user claims, while a single Lighthouse run remains a diagnostic tool.

Google's published thresholds are unchanged for the three metrics:

Metric	Good (p75)	Needs improvement	Poor
LCP	≤ 2.5 s	2.5 s – 4.0 s	> 4.0 s
INP	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS	≤ 0.1	0.1 – 0.25	> 0.25

An origin or URL group passes Core Web Vitals when all three sit in the good bucket at p75. A Lighthouse Performance score is a different artefact: it blends lab timings under a throttled environment and is useful for regression detection, not as a substitute for CrUX pass/fail. If you need a refresher on the three metrics themselves, start with What Are Core Web Vitals? A Practical Guide for 2026.

A useful Shopify benchmark therefore states four things up front: which clock (CrUX field versus Lighthouse lab), which URLs (homepage only versus collections, PDPs, cart), how scores are aggregated (single URL versus median or mean across pages), and the collection window. Platform marketing often quotes theme or “average store” figures without that scaffolding. Agencies managing twenty Shopify clients need the scaffolding more than another green screenshot.

Sources:

Shopify theme-level CrUX context from public data

Shopify's Performance team publishes aggregated Core Web Vitals performance by theme so merchants can compare popular themes under real Chrome traffic rather than a single lab screenshot. As of the 18 Aug 2026 update on their theme table, the median theme-level pass rates across listed themes were:

Metric	Median % of shops passing (theme table)
Largest Contentful Paint (LCP)	90.3%
Cumulative Layout Shift (CLS)	93.4%
Interaction to Next Paint (INP)	97.1%
Views passing all CWVs	82.0%

Those figures combine devices, cover recent theme versions with enough eligible shops, and still describe theme-level cohorts, not “every live Shopify store with every app enabled.” The same table shows wide floors and ceilings: all-CWV pass rates range from roughly 37% to 95% depending on the theme row, which is the first warning that platform averages do not replace store-specific monitoring.

Third-party research often cites a lower all-CWV pass rate for Shopify as a whole (for example ~45% in vendor CrUX summaries). The gap between ~45% store-wide claims and ~82% median theme-level “all CWVs” is not a mystery if samples, devices, and theme filters differ, so treat both as orientation and do not merge them into one scorecard column.

Source: Aggregated Core Web Vitals performance by Shopify Theme

Multi-page lab sample from Watcher's Shopify users

We keep Shopify-tagged storefronts in Watcher and run multi-page PageSpeed Insights analyses that store both Lighthouse lab metrics and CrUX field payloads when Google returns them. For this snapshot we took the latest domain report per Shopify-tagged lead with an aggregated payload (n = 64 stores; reports generated between April and September 2026). Each report averages Lighthouse metrics across the URLs selected for that domain (median 17 analysed pages per store; 1,070 page runs in total). Values below are store-level averages of lab runs, not single-URL CrUX p75s.

Mobile and desktop Lighthouse Performance

Slice	Mobile Performance (avg)	Desktop Performance (avg)
Minimum	26	35
25th percentile	37	57
Median	51	69
75th percentile	62	83
Maximum	86	99
Mean	51	69

Half of the sample sits at or below a mobile Performance average of about 51. Only 32 of 64 stores clear a mobile average of 50, and 9 of 64 clear 70; none of the 64 store averages reached 90 on mobile. Desktop is kinder in the same runs (median about 69), which matches what agencies see when a client forwards a desktop-only screenshot and assumes the site is fine.

Mobile lab Core Web Vitals timings (store averages)

Metric	Median	75th percentile	Notes in this sample
LCP (s)	9.8	14.5	0 / 64 store averages ≤ 2.5 s
INP (s)	0.30	0.41	15 / 64 store averages ≤ 0.20 s
CLS	0.02	0.07	55 / 64 store averages ≤ 0.1

CLS is the bright spot: layout stability is often already in a good lab band even when LCP is not. LCP is the structural problem. Multi-page mobile averages in the 8–15 s range do not mean every URL fails CrUX at that severity, but they do mean Lighthouse is consistently flagging heavy LCP candidates across templates. That is the signal agencies should take into a remediation backlog before arguing about a two-point Performance score change.

CrUX origin categories when field data exists

Not every lead has origin-level CrUX on the report. Where mobile origin overall category was present (n = 27), we saw 14 FAST, 8 AVERAGE, and 5 SLOW. Origin LCP was FAST on 22 of those stores, INP FAST on 22, and CLS FAST on 23. Field data is often healthier than multi-page lab averages on the same domains, especially for INP and CLS, because lab throttling and averaging across many templates punish media-heavy PDPs that may still pass origin-level CrUX when popular URLs are lighter.

Recurring Lighthouse opportunities

Across the 64 latest reports, the most common mobile opportunities were:

Opportunity	Stores where it appeared
Reduce unused JavaScript	61 / 64
Reduce unused CSS	52 / 64
Avoid multiple page redirects	26 / 64
Minify JavaScript	17 / 64
Minify CSS	10 / 64

Unused JavaScript is effectively the default Shopify finding in this sample. Theme code, app scripts, analytics, and personalisation layers compete for the same main thread that INP and Total Blocking Time care about. For ecommerce metric priorities beyond the three Core Web Vitals, see Performance Monitoring for E-Commerce: What Metrics Matter Most.

Why Shopify Core Web Vitals still vary store to store

Two shops on the same theme can land in different buckets for reasons that never appear in a theme marketing page:

App footprint. Review widgets, loyalty, chat, upsell drawers, and A/B tools add script weight on collection and PDP templates.
Media strategy. Hero video, large product galleries, and unprioritised LCP images dominate mobile LCP in lab runs.
Template mix. A clean homepage can hide a slow cart drawer or a script-heavy collection grid when you only test one URL.
Headless versus online store. Hydrogen or other custom storefronts change what source-level theme IDs reveal and how caching works.
Traffic shape and geography. CrUX inclusion and p75 values move with real visitor mix; lab runs do not.

Platform-level medians help set expectations in a roadmap review. They do not replace scheduled checks on the URLs that drive revenue. That is why we treat theme tables as context and multi-page samples as the operating view.

Global DTC Shopify cohort (lab and CrUX)

We also tracked a public high-visibility cohort tagged shopify-benchmark in Watcher (Allbirds, SKIMS, Kylie Cosmetics, Fashion Nova, Brooklinen, ColourPop, Steve Madden, Glossier, Netflix Shop, Mattel Creations). Six of those domains had multi-page Watcher lab reports in the lead pull above. On 7 Sep 2026 we also pulled mobile origin Chrome UX Report field data for the cohort via PageSpeed Insights (originLoadingExperience), so lab and field sit in separate tables rather than one mixed scorecard.

Lab multi-page averages (Watcher reports)

Brand	Domain	Mobile Performance (avg)	Desktop Performance (avg)	Mobile LCP avg (s)	Mobile CLS avg
Fashion Nova	fashionnova.com	37	60	8.6	0.05
Allbirds	allbirds.com	34	53	15.6	0.02
SKIMS	skims.com	33	52	9.1	0.04
Brooklinen	brooklinen.com	29	45	31.1	0.15
Kylie Cosmetics	kyliecosmetics.com	26	36	26.8	0.22
Netflix Shop	netflix.shop	26	41	15.7	0.15

These lab averages punish product-heavy template sets under throttling. They are not claims that every shopper sees a Performance score in the mid-20s.

Mobile CrUX at origin (PageSpeed Insights, Sep 2026)

Origin metrics are Chrome UX Report p75 values for phone traffic across the origin. CLS is shown on the usual 0–1 scale (PSI returns hundredths). “Passes all CWVs” means LCP, INP, and CLS are all in the good (FAST) bucket at p75.

Brand	Domain	Origin overall	LCP p75	INP p75	CLS p75	Passes all CWVs?
Allbirds	allbirds.com	Good	1.49 s (Good)	176 ms (Good)	0.00 (Good)	Yes
ColourPop	colourpop.com	Needs improvement	1.66 s (Good)	212 ms (Needs improvement)	0.15 (Needs improvement)	No
Kylie Cosmetics	kyliecosmetics.com	Needs improvement	2.02 s (Good)	319 ms (Needs improvement)	0.04 (Good)	No
Netflix Shop	netflix.shop	Needs improvement	2.06 s (Good)	221 ms (Needs improvement)	0.13 (Needs improvement)	No
Steve Madden	stevemadden.com	Needs improvement	2.09 s (Good)	245 ms (Needs improvement)	0.10 (Good)	No
Mattel Creations	creations.mattel.com	Needs improvement	2.10 s (Good)	314 ms (Needs improvement)	0.02 (Good)	No
Glossier	glossier.com	Needs improvement	2.17 s (Good)	239 ms (Needs improvement)	0.09 (Good)	No
Fashion Nova	fashionnova.com	Needs improvement	2.52 s (Needs improvement)	360 ms (Needs improvement)	0.20 (Needs improvement)	No
SKIMS	skims.com	Poor	2.64 s (Needs improvement)	204 ms (Needs improvement)	0.32 (Poor)	No
Brooklinen	brooklinen.com	Needs improvement	3.49 s (Needs improvement)	287 ms (Needs improvement)	0.13 (Needs improvement)	No

Homepage URL-level field rows can differ from origin (for example Fashion Nova’s homepage LCP was Good while origin LCP was Needs improvement), so use origin for brand-level scorecards and URL groups for template work.

Allbirds is the clearest split in this cohort: Watcher multi-page lab Performance averaged about 34, with lab LCP around 16 s, while mobile origin CrUX passed all three Core Web Vitals. Brand scale does not guarantee a field pass either, because only Allbirds cleared all three origin metrics in this snapshot and INP (and sometimes CLS) kept most of the other famous stores out of the good bucket even when LCP looked acceptable. If a client asks “are we slower than the big Shopify brands?”, compare their CrUX origin or Search Console URL groups to this table, and keep Lighthouse for regression hunting on the same money-path templates.

At the other end of our wider Watcher sample, smaller or carefully trimmed storefronts can clear mobile lab averages in the mid-70s to mid-80s (for example Beauty Connections, Valmont Wear, and Bäckerei Matzker in this pull). Those shops still run on Shopify. The gap versus the famous lab cohort is mostly implementation load: fewer competing scripts, lighter heroes, and fewer template surprises across the multi-page set.

Lab Lighthouse scores versus CrUX field data on Shopify

Use both clocks without mixing them in one column:

Question	Prefer
Does Google’s page experience view look healthy?	CrUX / Search Console / PSI field (p75)
Did last week’s theme or app change regress templates?	Scheduled Lighthouse (lab), same URL set
Are we comparing to Shopify’s theme table?	Theme CrUX aggregates (device mix, theme filter)
Are we comparing agency client A to client B?	Same tool, same URL roles, same aggregation

Watcher domain reports already separate lab score cards from field methodology notes (median of URL-level p75s where present, origin badge when available). Keep that separation in client decks. A green origin badge with a mobile Performance average of 40 is not a contradiction; it is a prompt to inspect which templates the lab average is punishing. For portfolio monitoring design, see Core Web Vitals Monitoring Checklist for Agencies and How to Set Up Automated PageSpeed Monitoring.

What to fix first when Shopify Lighthouse opportunities repeat

When unused JavaScript appears on nearly every store, a useful remediation order is usually:

Measure the money paths: homepage, top collections, top PDPs, cart, and checkout-adjacent templates, not a single marketing URL.
Cut or defer app scripts that are not required for first paint or first interaction on those templates.
Fix LCP candidates explicitly (image dimensions, priority hints, hero media weight) before chasing a Performance score vanity target.
Re-check CLS when banners, consent UI, or late-injected reviews shift layout after load.
Re-run the same URL set on a schedule so you can tell a real regression from run noise.

The detailed Shopify playbook for those steps lives in Shopify Speed Optimization: Core Web Vitals Guide for E-Commerce. Benchmark numbers stay honest when prioritisation stops here and the how-to lives in that companion post.

How to run a repeatable Shopify CWV cohort each month

A fixed process keeps each monthly refresh comparable:

Scope: mobile-first; LCP, INP, CLS; optional Lighthouse Performance as a lab companion metric.
URL roles: same template set each month (home, collection, PDP, cart at minimum).
Aggregation: decide in advance whether you report origin CrUX, URL-level field, or multi-page lab averages, and never mix them in one table column.
Guardrails: mark insufficient CrUX explicitly; record tool, date, and page count.
Reporting: publish median cohort values, share of stores passing field CWV when available, top gains and regressions, and hypotheses (apps, media, theme) labelled as hypotheses.

You can start wi

When LCP Moves and Nobody Deployed: Browser Release Cadence and Your 28-Day Field Window

Wed, 02 Sep 2026 22:12:54 +0000

Field Largest Contentful Paint in PageSpeed Insights can move while your release calendar stays empty. Chrome User Experience Report (CrUX) data is always a 28-day rolling average of real Chrome sessions. From Chrome 153 Stable on 8 September 2026, Chrome also moves to a two-week release cycle, so that same window can include more than one browser major with different paint and interaction behaviour. An amber field band after a quiet week is often population mix (who updated Chrome, which channel they use, how fast auto-update spreads), not proof that engineering shipped a regression on Tuesday.

We already separated pipeline lag from rolling-window lag in CrUX pipeline delays and late field data and explained why a verified fix can sit inside a green lab run and an amber field band in why your Core Web Vitals fix is not in CrUX yet. The gap here is the third clock agencies rarely label: browser release cadence inside the field window. When nobody deployed but field LCP drifts, you need release annotations on the same calendar as app, CDN, tag manager, and RUM changes, sample thresholds before you slice by exact Chrome major, and scheduled lab runs as same-week proof that the origin did not change.

Why field LCP can move when nobody deployed

CrUX and PageSpeed Insights field sections describe what real Chrome users experienced over roughly the past 28 days, not what your staging build measured yesterday. If the mix of Chrome versions, devices, networks, and journeys inside that window changes, the published p75 can move even when your HTML, CSS, and JavaScript bundles are byte-identical to last month.

Three non-deploy causes show up often in agency tickets:

Browser updates. A new Stable or Extended Stable channel release changes paint timing, image decoding, lazy-loading heuristics, or interaction scheduling for the same page. Users who auto-update mid-window contribute post-update sessions beside pre-update sessions in one aggregate.
Channel skew. Beta, Dev, and Canary users are a thin slice for most retail sites, but enterprise Extended Stable cohorts can lag Stable by weeks. A retail origin and a locked-down corporate audience can read different field bands on the same URL template.
Traffic mix. Campaign traffic, geography shifts, or seasonality change which templates dominate Chrome sessions. Origin-level field LCP can move when the homepage share of traffic falls while a slower category listing gains share, with no code change on either template.

Lab runs on a fixed URL answer whether your deploy changed the critical path. Field CrUX answers what Chrome users actually experienced across versions and journeys. Treating a field move as a deploy regression without checking browser and traffic mix sends engineering on a hunt for a commit that does not exist.

Chrome release cycle and Core Web Vitals: two-week Stable from Chrome 153

Google announced in March 2026 that Chrome will move from a four-week Stable cadence to a two-week cycle, starting with Chrome 153 Stable on 8 September 2026 (Chrome two-week release blog). Beta and Stable promotions arrive every two weeks on Desktop, Android, and iOS. Extended Stable keeps an eight-week cycle for enterprises that need longer validation windows (Chrome Enterprise Extended Stable).

The schedule compresses milestones quickly. Under the new table in Google's post, Chrome 153 Stable cuts on 25 August 2026 with public Stable on 8 September, while Chrome 154 Stable follows on 22 September. Firefox is running a similar experiment around Firefox 155 from 1 September 2026 (see community coverage linked from CSS Wizardry Web-Perf Wednesday 006). Performance teams that only annotated application releases in 2025 will need browser rows on the same calendar in 2026.

Release	Old four-week Stable (illustrative)	New two-week Stable (from Google table)
Chrome 153	Tue 22 Sep 2026	Tue 8 Sep 2026
Chrome 154	Tue 20 Oct 2026	Tue 22 Sep 2026

Smaller, more frequent browser releases are good for security and platform velocity. For field reporting they mean more opportunities for a 28-day CrUX window to span two majors with different Web Vitals behaviour, without any change on your origin.

How a 28-day CrUX window can span multiple browser majors

CrUX aggregates opted-in Chrome sessions into a rolling 28-day window. At any query, PageSpeed Insights and the CrUX API return a collectionPeriod with firstDate and endDate covering that blend (CrUX API documentation). The window advances daily: oldest day drops, newest day enters. There is no switch that flips the entire population to "only Chrome 153 sessions" on Stable release day.

Under a four-week browser cadence, one 28-day field window often covered one new Stable major plus tail versions. Under a two-week cadence, the same window can include two adjacent majors (for example 152 and 153) while auto-update propagates. Each major can shift LCP, INP, or CLS for the same URL because the browser pipeline changed, not because your LCP element or server timing changed.

Clock	What moves	Typical agency mistake
28-day CrUX window	Rolling average of Chrome sessions	Treating field p75 as "yesterday's score"
Chrome Stable cadence	Browser majors entering the window	Ignoring browser rows on the release calendar
App / CDN deploy	Origin HTML, assets, cache rules	Blaming deploys for browser-driven field drift
Lab schedule	Controlled PageSpeed Insights / Lighthouse runs	Expecting lab to explain field without dates

For metric definitions and why field percentiles behave differently from lab medians, start with our practical Core Web Vitals guide. For why lab and field are different instruments on the same URL, see synthetic versus real user monitoring.

Browser version in RUM: population mix vs a site regression

First-party Real User Monitoring (RUM) and CrUX answer different questions. CrUX is a public, privacy-thresholded view of Chrome traffic Google already collected. RUM is yours: you choose segments, retention, and alert rules. When practitioners search browser version RUM, they usually need to know whether a field shift is segment noise before they open a regression ticket.

Population mix means the aggregate changed because the audience composition changed: more sessions on Chrome 153, fewer on 152, a higher share of mobile on a slower network, or a campaign that sent traffic to a heavier template. Site regression means the same browser version and similar journey on the same URL got worse after your change (or after a third-party or CDN change you control).

Before you slice field data by exact Chrome major, set sample thresholds. Thin segments produce volatile p75 lines that look like regressions every week. Rules we use in client work:

Do not report URL-level p75 for a single Chrome major until you have enough sessions to trust the segment (exact cut-offs depend on traffic; treat very small counts as directional only).
Prefer unsegmented LCP, INP, and CLS as the headline series in retainer reports; use browser-major slices in appendix slides for engineers.
Compare like with like: same form factor, same URL or origin scope, same collection period dates.
Pair every segmented chart with an unsegmented line so leadership sees whether the whole population moved or only one slice.

Harry Roberts framed the risk clearly in Web-Perf Wednesday 006: faster browser releases change the RUM population you are averaging, not just the code on your server. Agencies that report "Chrome 152 LCP" and "Chrome 153 LCP" without sample sizes invite false escalations every Stable Tuesday.

Put Chrome Stable on the same calendar as deploys and CDN changes

Performance regressions are easier to debug when every graph annotation uses the same calendar. Most teams already mark application deploys, CDN cache rule changes, tag manager publishes, and major marketing releases. Browser Stable and Beta dates belong on that same timeline from September 2026 onward.

Checklist we ask account and engineering leads to maintain:

Chrome Stable and Early Stable dates for Desktop and Android (at minimum) through the next two milestones.
Extended Stable notes for clients with locked-down browser policies.
Firefox milestone dates when the site has meaningful non-Chrome share in RUM.
RUM or CrUX instrumentation changes (new snippet, different sampling, new soft-navigation handler).
Named owner who updates the calendar within one business day of a release (not "the platform team" in the abstract).

When field LCP moves in the weekly report, the first question is not "what did we ship?" but "what changed in the window: browser, traffic, CDN, tags, or code?" A single annotated timeline prevents the "nobody deployed" argument from turning into a trust fight. The ops checklist (release owner, browser rows beside deploy rows) is the agency ritual; the sections above carry the CrUX math and monitoring split.

Sample thresholds before you slice field data by Chrome major

Segmentation is useful after thresholds, not before. If Chrome 153 represents 4% of sessions in a 28-day URL-level slice, its p75 is not a client-ready KPI. Use thresholds to decide when a segment earns its own row in the report.

Segment type	When to show in client body	When to keep internal
Unsegmented origin or URL field p75	Always, with `collectionPeriod` dates	n/a
Mobile vs desktop field	When both pass eligibility	Thin desktop slice on mobile-heavy sites
Chrome major (e.g. M152 vs M153)	When each major has stable sample counts	Single-digit session majors
Beta / Dev channel	Rarely	Almost always appendix only

In first-party RUM, configure minimum session counts per segment before alerts fire. In CrUX-only workflows, respect Google's eligibility and popularity rules (CrUX methodology): missing URL-level data is often "not enough Chrome sessions," not a tooling failure. Say that explicitly in the report footnote.

Use scheduled lab runs as same-week proof when field CrUX drifts

Unsegmented field series are the executive headline. They answer "how are our users doing in aggregate?" without opening a statistics debate on Chrome 152.3 versus 153.0. Browser-major slices are diagnostic tools for engineers checking whether a shift correlates with a Stable release line on the calendar.

Scheduled lab runs provide same-week proof that the origin did not change:

Run PageSpeed Insights or Lighthouse on priority URLs on a fixed schedule (how to schedule PageSpeed monitoring across a portfolio).
Store run timestamps beside field collectionPeriod dates in the client-ready Core Web Vitals report outline.
If lab LCP and INP stay inside budget while field p75 drifts, investigate population mix and browser cadence before you roll back a deploy.
If lab and field move together after a deploy, treat it as a site change regardless of browser week.

Spot checks fail this test because Tuesday's paste and Thursday's paste are not a history. PageSpeed Insights versus automated monitoring is where we unpacked why portfolios need schedules, not heroic manual runs. Apogee Watcher holds that lab clock for multi-tenant teams: scheduled tests, budgets, alerts, and CrUX field numbers when Google returns them beside the same URL row. We do not replace first-party RUM segmentation. We keep lab verification repeatable while you interpret field drift.

Browser mix vs fix lag and CrUX pipeline delay: three lag types

Agencies confuse three lag types. Each needs a different sentence in the client deck.

Lag type	Cause	What the client sees	Primary doc
Rolling-window fix lag	Pre-fix sessions still inside 28 days after a deploy	Slow field improvement after a verified lab win	[Why your fix is not in CrUX yet](https://apogeewatcher.com/blog/why-core-web-vitals-fix-not-in-crux-yet-28-day-window)
Pipeline / publication lag	CrUX API, History, or BigQuery publish late	Same field values two days straight; missing weekly point	[CrUX pipeline delays](https://apogeewatcher.com/blog/crux-pipeline-delays-late-field-data-client-reports)
Browser population mix	New Chrome majors enter the window without a site deploy	Field moves while lab flat; shift aligns with Stable calendar	This post

Fix lag is about your sessions aging out. Pipeline lag is about Google's publish schedule. Browser mix is about whose Chrome sits inside an already-published window. A field LCP move with no deploy and flat lab budgets is often the third row, especially from September 2026 when two-week Stable releases overlap the 28-day average more often.

How agencies should monitor and report while browser mix shifts

From August through October 2026, expect more "false regression" tickets. Build the monitoring plan around dated clocks, not vibes.

Weekly field read with firstDate and endDate on every table row. No naked p75 without collection period.
Daily or thrice-weekly lab on money URLs through the Chrome 153 and 154 Stable window.
Release calendar with browser Stable rows visible to SEO and engineering, not only infra.
Executive one-liner in the retainer PDF: "Field CrUX is a 28-day rolling average of real Chrome users; browser Stable releases can move field bands without a site deploy; lab trends below are same-week origin verification."
Escalation rule: open a code regression when lab budgets break or when unsegmented field and lab move together after a deploy; investigate population mix when lab is flat and field drifts across a Stable line.

Portfolio teams scale this with per-client organisations, shared budget templates, and alerts that fire on lab thresholds even when field data lags. That is the layer Apogee Watcher adds on top of Search Console and whatever RUM vendor the client already pays for.

FAQ

Can Core Web Vitals change without a website update?

Yes. CrUX field metrics reflect real Chrome sessions over a rolling 28-day window. Browser updates, traffic mix shifts, and eligibility changes can move field p75 without any deploy on your origin. Lab runs on fixed URLs help prove whether the site changed.

How does Chrome's two-week release cycle affect CrUX data?

More frequent Stable releases mean a 28-day field window can include two browser majors with different performance behaviour. Field LCP or INP can shift as auto-update spreads, even when your code is unchanged. Annotate Chrome Stable dates on your release calendar from Chrome 153 onward.

Should I segment RUM by browser version after Chrome 153?

Segment when sample sizes support it, and keep an unsegmented headline series for clients. Thin Chrome-major slices produce noisy charts. Set minimum session thresholds before alerts or report rows use a single major.

Is a field LCP move a

CrUX Pipeline Delays: What Late Field Data Means for Client Reports

Thu, 27 Aug 2026 08:14:00 +0000

CrUX field numbers in a client report carry two dates most teams never write on the slide: when Google published the aggregate, and which 28 days of Chrome sessions sit inside it. PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, and BigQuery each refresh on a different schedule. Field Largest Contentful Paint and Interaction to Next Paint are always a rolling 28-day average on top of that schedule. Lab scores from a scheduled PageSpeed Insights run can turn green the morning after a deploy while the field band beside them stays amber for weeks. None of those contradictions mean the fix failed. They mean engineering, SEO, and the client are reading different clocks without labelling them.

Agencies lose retainer hours when those clocks get treated as one bug. Engineering trusts the lab trend; SEO trusts Search Console; the client trusts whichever PageSpeed Insights paste arrived in email first. Without a shared "field data as of" line, a routine CrUX pipeline delay reads like negligence. What follows separates pipeline lag (when Google publishes CrUX) from the 28-day rolling window (what CrUX averages once published), maps the Chrome UX Report update schedule across API, History, and BigQuery, and gives copy-ready footnotes for client-ready Core Web Vitals reports. For why a shipped fix can still sit inside a green lab run and an amber field band for weeks, see why your Core Web Vitals fix is not in CrUX yet. For where to read field history after the CrUX Dashboard retirement, see where to get TTFB, INP, and field history.

What CrUX data delay means for agency client reports

"CrUX data delay" shows up in two conversations that get mixed together in client Slack. The first is publication lag: Chrome User Experience Report (CrUX) data moves through Google's pipeline before it appears in PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, or BigQuery. The second is rolling-window lag: even when publication is on time, field percentiles describe roughly the past 28 days of real Chrome sessions, so a Tuesday deploy cannot rewrite Friday's field screenshot.

Client reports go wrong when those two lags are treated as one bug. A PageSpeed Insights field section that still shows last week's collectionPeriod end date is often a short pipeline or API refresh issue, not proof that users are still suffering pre-fix timings. A field band that barely moves for three weeks after a large fix is usually the rolling window doing its job, not a broken pipeline. Your report should name which lag you are discussing before you paste a number.

Lag type	What the client sees	Typical duration	What to cite in the report
Pipeline / publication lag	Same field values two days in a row; History weekly point missing	Hours to a few days; rare multi-day slips on weekly/monthly surfaces	CrUX release notes; `collectionPeriod` dates in PageSpeed Insights or API
Rolling-window lag	Field LCP or INP improves slowly after a verified lab win	Days to ~28 days depending on traffic and fix size	[28-day CrUX window](https://apogeewatcher.com/blog/why-core-web-vitals-fix-not-in-crux-yet-28-day-window); lab trend for same-week proof
Monthly BigQuery lag	SQL dashboards feel a month behind PageSpeed Insights	~5 weeks from collection month to second-Tuesday release	BigQuery `YYYYMM` table label; do not use for weekly client scorecards

Account managers do not need the full pipeline diagram. They need one sentence in the executive summary: field metrics are a rolling average of real-user Chrome data, refreshed on Google's schedule; lab metrics below are our same-week verification. That single line prevents most "your report is wrong" threads when CrUX is merely late, not wrong.

Chrome UX Report update schedule: daily API, weekly History, monthly BigQuery

Google publishes CrUX through several surfaces that update on different cadences. Teams that check only one surface often assume the whole ecosystem is broken. PageSpeed Insights field data and the daily CrUX API answer "what does field say this week?" CrUX History API and CrUX Vis answer "how has the trend moved over the past months?" BigQuery answers "what did the origin look like in March?" for analysts who accept monthly grain and query cost. Pick the surface that matches the question before you paste a number into a client deck.

According to Chrome's CrUX API documentation, the public dataset refreshes daily around 04:00 UTC on a best-effort basis with no fixed service-level agreement. Responses include a collectionPeriod with firstDate and endDate so you can see whether today's query returned a new aggregation window or the same window as yesterday. Chrome's docs also note that the API is typically about two days behind "today" in Pacific time, which is normal processing lag rather than a stalled deploy on your site.

The CrUX History API publishes weekly series: each point covers a 28-day window whose end dates are spaced seven days apart, with up to about 40 historical points. Weekly publication is aimed at trend charts in CrUX Vis and custom dashboards, not same-day deploy proof. CrUX on BigQuery releases on the second Tuesday of the month following each collection period, which is why BigQuery-only workflows feel like a month-long CrUX data delay even when PageSpeed Insights has already moved.

Surface	Update cadence	Best for client reports	Delay clients often misread
PageSpeed Insights field section	Daily (~04:00 UTC refresh)	Current origin/URL field p75 with collection dates	Rolling 28-day average, not yesterday's deploy
CrUX API (`queryRecord`)	Daily	Automated field snapshots; same `collectionPeriod` as PSI	~2-day processing lag behind calendar "today"
CrUX History API / CrUX Vis	Weekly (Mondays typical)	Trend slides in QBR decks	New weekly point missing after a holiday Monday
Search Console CWV report	Aligned with CrUX field base	SEO status badges clients already recognise	Same rolling window as PSI; not lab-on-demand
BigQuery `chrome-ux-report`	Monthly (second Tuesday)	Long-range origin analysis, custom SQL	Entire month feels "late" vs daily PSI

When you build a client-ready Core Web Vitals report outline, put daily or weekly field numbers in the scorecard and relegate BigQuery charts to appendix slides for analysts. Mixing monthly SQL exports into a weekly status email is how agencies accidentally tell a client their site regressed when PageSpeed Insights field data had already turned green.

Why CrUX pipeline delays happen beyond the rolling window

The 28-day rolling average is predictable. CrUX pipeline delays are the extra slips: processing backlog, holiday staffing, connector outages on legacy Looker paths, or incidents that delay a weekly History release while the daily API still updates. Google's CrUX release notes are the authoritative place to check whether a missing weekly point is your origin or the whole dataset. The May 2026 notes, for example, mention a slight delay to the weekly CrUX History API and CrUX Vis release that was resolved separately from the monthly BigQuery publish.

Pipeline incidents are not the same as "my fix did not work." During a History API slip, CrUX Vis may show a flat line for one week while PageSpeed Insights field sections still advance their collectionPeriod end date on schedule. During heavy monthly release weeks, teams that relied on the retired CrUX Dashboard connector sometimes saw monthly bars pause even though the API moved. After the CrUX Dashboard retirement, those connector failures are less common, but weekly and monthly surfaces still batch work differently than the daily API. A report that mixes a Monday lab run with a weekly History chart and no dates on either axis will look inconsistent even when Google published everything correctly.

Low-traffic URLs add a different kind of delay that looks like a pipeline fault. CrUX omits URL-level field data when sample sizes are too thin, and PageSpeed Insights may show origin-level field bands while the URL you changed stays empty. That "no data" state can persist across daily refreshes until enough Chrome sessions accumulate. It is eligibility and popularity filtering, not a stuck ETL job. Google's CrUX methodology documents discoverability and popularity rules. Your footnote should say URL-level field data not available; origin-level field shown when that is what the tool returned. Holiday weeks add the same confusion: a report drafted on the Tuesday after a long weekend may pair a fresh lab run with a History chart whose endDate still ends on the previous Saturday because the weekly job has not published yet.

In our experience, the CrUX Google Group threads that age badly inside agencies are the ones where nobody wrote down which surface was checked. Standardise on PageSpeed Insights or the daily API for current field and CrUX Vis for trend. When a weekly point is missing globally, link the release notes in the report caption so the client sees you checked for a pipeline slip rather than ignoring a regression.

How late CrUX field data affects client Core Web Vitals reports

Late field data changes the story in client reports even when engineering already closed the ticket. Checkout field Interaction to Next Paint can stay amber while the rolling window is only halfway through shedding pre-fix sessions. Origin field Largest Contentful Paint can look green while the product listing URL the client cares about never earns URL-level CrUX. A weekly trend chart can sit flat for one publication cycle because History API ran late, so leadership assumes performance work stalled. Each pattern needs its own sentence in the report, not a generic "CrUX is slow" disclaimer.

Search Console status badges trail the same CrUX base as PageSpeed Insights field data. A Needs improvement label in week one after a deploy is expected when the rolling window still contains mostly pre-fix traffic. Clients who treat Search Console as a real-time monitor will forward screenshots that contradict your lab appendix unless you date both artefacts and explain that Search Console updates on CrUX's schedule, not on deploy day.

Executive summaries that only cite field numbers make pipeline delays look like negligence. If the headline says mobile LCP is still 3.1s without field data through 9 Aug and lab homepage 2.3s on 12 Aug runs, the client will compare your PDF to their own PageSpeed Insights paste from a different collectionPeriod. Trust breaks fast. One dated footnote fixes most of that.

Trend slides built only from BigQuery or weekly History can miss a step change that daily PageSpeed Insights already shows in the collectionPeriod end date. Daily API checks without History miss slow drifts that only become obvious across six weekly points. Multi-site portfolios amplify the noise: one client's field data updates on schedule while another's URL never earns CrUX eligibility, and a portfolio table without per-row collection dates looks like you ignored a site when the pipeline returned no data legitimately.

The operational fix is to treat field metrics as dated lagging indicators in every client-facing table and lab metrics as scheduled verification with run timestamps. That split matches how we described lab versus field clocks in synthetic versus real user monitoring and in PageSpeed Insights versus automated monitoring. Field answers what Google will eventually show in search tooling. Lab answers whether your release is healthy on the URLs you monitor.

How to annotate client reports with field data collection dates

Every field number in a client report needs a collection window beside it. PageSpeed Insights has displayed collectionPeriod dates since late 2024; the CrUX API has exposed firstDate and endDate since 2022. If your report omits them, the client will supply their own assumed "as of today" date when they re-test.

Add these elements to the scorecard and executive summary from our client report template:

Executive summary footnote (copy-ready):

Field Core Web Vitals below are 75th-percentile values from Google's Chrome UX Report, averaged over a rolling 28-day window. Collection period: {firstDate} to {endDate} (source: PageSpeed Insights / CrUX API). Lab scores are scheduled PageSpeed Insights Lighthouse runs on {run dates} on the URLs listed in the appendix.

Scorecard column headers:

Metric	Mobile field (CrUX p75)	Mobile lab (scheduled)	Collection period (field)	Last lab run
LCP	2.8s	2.1s	15 Jul to 11 Aug 2026	12 Aug 2026

Trend chart caption:

Weekly points: CrUX History API (28-day windows ending Saturdays). If the latest weekly point is missing, check CrUX release notes for pipeline delays before interpreting a flat line.

When field and lab disagree, use a single explanatory line rather than a paragraph of theory:

Field LCP remains amber because CrUX still includes sessions from before the 4 Aug image fix. Lab LCP on the same URL has been below 2.5s on daily scheduled runs since 5 Aug. We expect field to follow as older sessions roll out of the window.

When CrUX returns no URL-level field data, state what you showed instead:

URL-level CrUX data is not available for /checkout (insufficient Chrome traffic). Origin-level mobile LCP is shown below; lab monitoring covers /checkout directly.

Account managers can paste those lines without opening the CrUX API. Technical leads should store firstDate, endDate, and lab run timestamps in the same spreadsheet or monitoring export you already use for multi-site portfolios, so the dates are not retyped by hand each month.

Use synthetic monitoring while CrUX field data is late

Pipeline lag and rolling-window lag both create a gap between deploy and field proof. Synthetic monitoring fills that gap with scheduled lab runs on the URLs you choose, on a clock you control. It does not replace CrUX for Search Console or PageSpeed Insights field reporting. It gives the client something credible to read while Google's publication schedule and 28-day average catch up.

A practical agency workflow during a CrUX delay week:

Baseline before change. Capture mobile and desktop lab LCP, INP, and CLS on priority URLs, with run dates stored alongside any field collectionPeriod you quote.
Increase schedule frequency on touched URLs for two weeks after deploy (daily or every two days on checkout and homepage, weekly on long tail), matching the priority model in how to schedule PageSpeed monitoring.
Set lab budgets and alerts so a regression during the wait still notifies someone, using thresholds from a shared performance budget template.
Check field once per week, not every morning. Note whether endDate moved and whether release notes mention a global History API delay.
Ship the client report with both clocks labelled. Lab trend proves the release; field dates prove you are not hiding behind a stale screenshot.

Apogee Watcher runs that split for multi-tenant teams: scheduled PageSpeed Insights-backed lab tests across many client sites, CrUX field numbers when Google returns them beside the same run, budgets and alerts while field data lags, and organisation-level views so agencies are not pasting PageSpeed Insights links into separate spreadsheets per client. We do not shorten Google's pipeline or replace first-party real-user monitoring. We give you a repeatable lab clock next to the field clock Google publishes, layered onto the SEO and observability tools you already use.

<a href="https://

Treo vs Apogee Watcher: CrUX Scale, Competitor Benchmarks, and Agency Portfolios

Mon, 24 Aug 2026 09:02:00 +0000

After the CrUX Dashboard and Looker Studio report retired, many teams rebuilt their field-data workflow from PageSpeed Insights, Search Console, and third-party CrUX explorers. Treo is one of the products agencies shortlist when they want CrUX at portfolio scale without writing BigQuery jobs. Apogee Watcher addresses a related but different bottleneck: keeping scheduled lab checks, budgets, and alerts aligned across many client sites when URL lists change every sprint.

Both products show lab and field context. Both matter to agencies. The decision is usually workflow fit, not which logo wins a feature grid. Below we compare Treo and Watcher on CrUX depth, competitor views, multi-site operations, and price bands. Figures change; verify limits on Treo pricing and Apogee Watcher pricing before you buy.

What Treo is built for: CrUX scale and competitor benchmarks

Treo markets itself around the Chrome User Experience Report: raw field data, historical trends, connection and country breakdowns, and competitor comparisons without standing up your own BigQuery pipeline. Public materials emphasise large CrUX URL budgets (from dozens on the free tier to five figures on Scale and Enterprise), multi-year retention, and views that go beyond the p75 snapshots many free tools show.

That positioning matters when your brief is field exploration at scale:

You need hundreds or thousands of URLs in CrUX with history, not just origin-level Search Console summaries.
You want to chart competitors beside your client on LCP, INP, or CLS using the same CrUX source.
You export or API-pull field series into your own reporting stack (paid tiers).

Treo also adds scheduled Lighthouse monitoring on paid plans, with tiered page counts and frequency trade-offs (for example, hourly checks consume more capacity than eight-hour cadences). The free tier is CrUX-only: useful for evaluation, not for lab regression alerts across a retainer.

The screenshot above is from Treo’s public product pages: connection mix by geography on a world map, one of the views teams use when they explain field data to stakeholders who will never open BigQuery. If your job is “show me five years of CrUX for this URL set and my competitors,” Treo is aimed at that job.

For where CrUX still lives inside Google’s own surfaces after dashboard retirement, see CrUX Dashboard Retired: Where to Get TTFB, INP, and Field History.

What Apogee Watcher is built for: a web performance monitoring tool for agency portfolios

Apogee Watcher is a multi-tenant pagespeed monitoring platform built for agencies. We run scheduled tests through Google’s PageSpeed Insights API, which returns Lighthouse lab metrics plus CrUX field slices where Google publishes them for the tested URL. We emphasise organisations, sites, roles (Admin, Manager, Viewer), automated page discovery from sitemaps and crawl paths, performance budgets, and email alerts when thresholds breach.

We do not offer Treo-scale CrUX URL inventories or built-in competitor benchmarking boards. We do not replace a CrUX explorer when your primary question is “how does this competitor’s field INP trend over three years on five hundred URLs?”

We are strong when:

You manage many client properties and need scheduled lab coverage without maintaining separate spreadsheets per site.
Discovery must catch new templates and campaign landers before someone remembers to add URLs manually.
Account managers need read-only access without touching API quotas.
Entry price and predictable tiers matter for monitoring as its own retainer line.

Setup patterns and discovery behaviour are in Getting Started with Apogee Watcher: A Step-by-Step Setup Guide. For how synthetic schedules relate to field proof, pair with When to Use Synthetic vs Real User Monitoring for Performance.

Treo vs Apogee Watcher: CrUX monitoring tools compared

Use this table as a decision grid, not a scorecard. Confirm numbers on each vendor site.

Topic	Treo (typical positioning)	Apogee Watcher
Primary strength	CrUX URL scale, history, competitor benchmarks	Multi-site scheduled PSI monitoring, discovery, agency RBAC
Test engine	CrUX-native; Lighthouse on paid tiers	PageSpeed Insights API (Lighthouse lab + CrUX where available)
CrUX URL budgets	50 free; 1K–20K+ on Vital–Scale; 50K+ Enterprise	Per-URL CrUX via each PSI result; no competitor boards
Competitor benchmarking	Built into product narrative	Not a core feature
Data retention (public FAQ)	Unlimited historical access via UI/API	30–365 days by plan (confirm on pricing)
Team members	5–50 on paid tiers	Unlimited on published tiers
Entry paid pricing	Vital from $75/mo (CrUX + Lighthouse)	From $9/mo Personal through $199/mo Agency
Free tier	50 CrUX pages; no Lighthouse	Free tier available (confirm current limits)
API	Pro tier and above	Product API focus differs; confirm live features
Best day-one use	Field exploration, competitive charts, large CrUX lists	Portfolio lab monitoring without per-client instrumentation

Treo’s paid entry at $75/mo reflects CrUX infrastructure and history, not a stripped-down lab runner. Watcher’s lower entry reflects a different scope: scheduled synthetic monitoring and agency workflow, not five-figure CrUX URL catalogs.

Broader tool taxonomy (where Treo sits beside GTmetrix, DebugBear, and PSI) lives in Comparing PageSpeed Monitoring Tools: Features Agencies Need. For another premium synthetic comparison with optional RUM, see DebugBear vs Apogee Watcher: Synthetic Monitoring for Multi-Site Teams.

When Treo is the better primary choice

Favour Treo when CrUX is the product, not a sidebar on lab reports:

Competitive narratives: Monthly reviews that compare your client to named competitors on Core Web Vitals using the same CrUX source.
Large URL lists in field data: Category or marketplace sites where you must monitor hundreds of URLs in CrUX, not ten hero routes in lab only.
Long historical arcs: Multi-year trends for leadership decks; Treo’s marketing emphasises five-year history and unlimited retention in FAQ materials.
Export and API: Pro/Scale customers pulling JSON series into BI tools without maintaining BigQuery pipelines.

If first-party RUM on the client origin is also non-negotiable, Treo still is not a RUM vendor; you would add analytics or a RUM product separately. PageVitals vs Apogee Watcher covers a different RUM-first angle for WordPress-heavy stacks.

When Apogee Watcher is the better primary choice

Favour Watcher when the retainer is “keep these URLs inside budget and tell us when a deploy regresses”:

Many sites, modest field ambition: You need lab schedules and CrUX context on priority URLs, not a five-thousand-row CrUX inventory on day one.
URL churn: Marketing publishes routes faster than spreadsheets update; discovery reduces stale monitor lists.
Role separation: Managers tune budgets; viewers read dashboards; admins own billing without sharing one login.
Cost at scale: Monitoring line items must survive procurement at ten to thirty sites; entry tiers matter.

Watcher does not try to win on competitor benchmarking charts. We try to win on operational coverage: the same URLs tested on a cadence, with alerts that reach a human. Manual PSI rituals stop scaling long before CrUX URL math becomes the bottleneck; that case is in PageSpeed Insights vs Automated Monitoring: When Manual Checks Aren't Enough.

Layer Treo and Watcher instead of forcing one vendor

Many agencies split roles:

Treo for field exploration, competitor slides, and CrUX-heavy discovery when a client asks “how do we compare in the market?”
Watcher for scheduled lab monitoring, budgets, and regression alerts across the whole portfolio.

That is the same layer-don’t-replace principle we use elsewhere: add CrUX exploration beside synthetic monitoring; do not pretend one subscription replaces both jobs. A team can run Treo on strategic URL sets and Watcher on every retainer property’s priority routes without duplicating work if roles are explicit in the SOW.

Neither tool replaces Search Console’s CWV report or one-off PSI checks before a sponsor call. Keep those; assign each tool a named owner in the runbook.

FAQ

Can Apogee Watcher replace Treo for large-scale CrUX work?

They overlap on “performance monitoring” but optimise for different questions. Treo is the stronger fit for large CrUX exploration and competitor benchmarking. Watcher is the stronger fit for multi-tenant scheduled PageSpeed monitoring with discovery and agency roles. Many teams use both.

Does Apogee Watcher replace Treo’s CrUX history?

No. Watcher shows CrUX where PSI returns field data for each tested URL and stores lab history for trends and alerts. It does not replicate Treo-scale CrUX URL budgets or competitor boards.

Can I start on Treo’s free tier and add Watcher later?

Yes. Treo’s free plan (50 CrUX pages, no Lighthouse) suits evaluation of field views. When you need scheduled lab checks across many client sites, add Watcher rather than stretching Treo’s Lighthouse limits alone.

Which tool is cheaper for an agency with twenty sites?

Compare total cost with your URL counts and roles, not headline price alone. Watcher’s published tiers start lower; Treo’s Vital plan at $75/mo includes CrUX and Lighthouse capacity you may not need on every retainer. Run the maths for CrUX pages, Lighthouse pages, seats, and retention you actually use.

Do either tool replace BigQuery CrUX exports?

Treo abstracts BigQuery for dashboard and API users. Watcher does not. If you need custom SQL across the public dataset, you still use BigQuery or a vendor built for that scale; see our CrUX replacement guide linked above.

If you want scheduled PageSpeed checks across client sites with budgets and discovery, start from pricing or run a free domain check. If your brief is CrUX competitor charts at thousands of URLs, evaluate Treo on its own terms and layer monitoring where lab cadence still matters.

References

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

Mon, 10 Aug 2026 17:57:00 +0000

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:

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.
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.
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.
Pull Search Console CWV status monthly for SEO owners. Treat it as a lagging group report, not a deploy gate.
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 fo

Why Your Core Web Vitals Fix Isn't in CrUX Yet (28-Day Window)

Tue, 28 Jul 2026 08:12:00 +0000

You shipped the fix on Tuesday. Hero images are compressed, the heavy tag is gone from the homepage, and Lighthouse on mobile looks healthier than Monday's run. Someone pastes the PageSpeed Insights link into Slack with a green check. On Thursday the account manager forwards a Search Console screenshot: the URL group is still Needs improvement, or field LCP in PageSpeed Insights is still amber. The instinct is to assume the deployment failed or that Google is ignoring the work. In most cases the change is real. Chrome User Experience Report (CrUX) data has not finished rolling the old sessions out of its window yet.

We already covered why lab and field can disagree on the same URL in synthetic versus real user monitoring. The gap below is the timeline inside that split: how CrUX's 28-day rolling average updates, why third-party and CDN fixes take weeks to show, and what to monitor so the client sees proof before Search Console turns green. If you only remember one rule, remember that field screenshots trail lab verification by design.

How CrUX data updates: the 28-day rolling average

CrUX is Google's public dataset of real-user Core Web Vitals from opted-in Chrome sessions on eligible origins and URLs. It is not a lab run. It is not a snapshot taken on the day you ship. According to Chrome's CrUX API documentation, the numbers in PageSpeed Insights, the CrUX API, and related tools are a 28-day rolling average: at any moment you are looking at experiences collected across roughly the past four weeks, not "yesterday after the release."

That design smooths day-to-day traffic noise. A busy campaign Friday or a quiet Sunday no longer swings the published p75 on its own. The trade-off is latency. Sessions collected before your fix stay inside the window until they age out, so a green lab run on ship day can sit next to amber field bands for days or weeks. Google's CrUX versus RUM differences article is blunt: CrUX uses a 28-day sliding window and you cannot shorten it. First-party RUM can show smaller time ranges if you accept more noise.

PageSpeed Insights and the daily CrUX API refresh that rolling window roughly every day, with a short processing lag (Chrome's docs put the API about two days behind "today" in Pacific time). Search Console's Core Web Vitals report draws on the same CrUX base, so client screenshots lag for the same reason. Monthly BigQuery CrUX tables and the weekly History API still describe overlapping 28-day collection periods; they do not collapse the window into a single-day score. For metric definitions before you argue about timelines, start with our practical Core Web Vitals guide.

When does CrUX update after a Core Web Vitals fix?

There is no single calendar day when CrUX flips to your new numbers. Each daily refresh drops the oldest day and adds a newer one. The published p75 moves gradually as post-fix traffic replaces pre-fix traffic inside the window. Teams often expect a step change on day 29. What you usually get is a curve: modest movement in the first week if traffic is high and the fix is large, clearer separation after two to three weeks, and a cleaner field result once most of the window is post-fix sessions.

Traffic volume matters. A high-traffic homepage pushes more new experiences into the aggregate each day, so old sessions lose weight faster. A low-traffic landing page can keep sparse pre-fix samples in the mix longer, and some URLs never earn stable URL-level CrUX at all. Origin-level field data can look better or worse than a single template depending on which URLs dominate Chrome traffic. Eligibility rules, form factor splits (phone versus desktop), and thin samples still produce "no data" in PageSpeed Insights even when lab runs succeed every morning.

So "when does CrUX update?" has two answers at once. The dataset refreshes often (daily for the API and PageSpeed Insights field numbers). The value you care about is always a rolling average, so field proof for clients trails lab proof by design. When tools expose firstDate and endDate on the collection period, put those dates on the report. Without them, a screenshot looks like a live score when it is really a four-week blend.

Lab scores versus CrUX field data after a Core Web Vitals fix

Lab and field answer different questions on different clocks. A scheduled Lighthouse-style run through PageSpeed Insights measures a controlled load on a URL you choose, with a fixed device profile and network emulation, so you can compare Tuesday's ship to Monday's baseline under the same conditions. Field CrUX reports what real Chrome users experienced across devices, networks, cache states, and journeys over the rolling window. The short version for this lag: lab confirms the fix shipped; CrUX confirms enough real users have lived with it for the aggregate to move.

Signal	Clock	Best use after a fix
Scheduled lab (PageSpeed Insights / Lighthouse)	Same day, every run	Prove the change on priority URLs before the client meeting
CrUX field (PageSpeed Insights, Search Console, CrUX API)	28-day rolling average	SEO and page-experience reporting once traffic ages in
First-party RUM	Configurable windows	Segmented proof if a client already has a snippet

Trouble starts when one PageSpeed Insights paste is treated as both engineering proof and Search Console status. Spot checks also fail to scale once you manage many clients; that gap is why PageSpeed Insights versus automated monitoring exists. Keep lab history on a schedule so you can show before/after without waiting for CrUX. Label field screenshots as lagging indicators, not same-day scorecards.

Why Core Web Vitals fixes take weeks to show in CrUX

Not every fix ages out of the rolling window at the same speed. Some lab improvements barely touch the field mix clients care about. The three cases below are the ones that show up most often in agency tickets after a "green" lab paste.

Third-party script removal and CrUX lag

Removing a heavy tag often improves lab Total Blocking Time and Interaction to Next Paint on a clean run the same day. Real users may still hit cached HTML, tag-manager containers that update later, or secondary templates where the tag remains. Old sessions with the heavy script stay in CrUX until they roll off. Lab green on the homepage is necessary; it is not enough until enough post-removal traffic fills the window.

CDN and cache-rule changes

CDN and cache-rule changes can cut Time to First Byte and Largest Contentful Paint in controlled tests within hours. Field users on different geographies, ISPs, and cache hit rates still contribute pre-change timings for weeks. Partial adoption of a new point of presence or a staggered purge means CrUX blends both eras. Expect Search Console origin status to move slowly even when synthetic runs look clear.

Theme, template, and image work

Theme, template, and image work (hero sizing, font loading, layout reserves for CLS) shows up cleanly in lab when you test the exact URL you changed. CrUX aggregates experiences across templates that share an origin. If only the blog template improved and the product listing still shifts, origin-level field bands can stay amber while your ticket looks closed. Align monitored URLs with the journeys that generate Chrome traffic, rather than the single page you edited in staging.

In our experience, the client conversation goes better when you separate three statements: (1) we verified the fix in lab on these URLs on these dates, (2) CrUX will keep including pre-fix sessions for up to about 28 days, and (3) we will watch field percentiles weekly without treating every daily wiggle as a regression. That framing prevents "the fix did not work" tickets in week one. It also gives account managers a shared script so engineering and SEO are not contradicting each other in the same thread.

How to monitor Core Web Vitals while CrUX data updates

Waiting passively for CrUX leaves a gap clients notice. They pay for confidence during the lag. A green Search Console badge later is not a substitute for that week. Set a monitoring plan that treats lab as the deploy gate and CrUX as the lagging SEO report.

Baseline before you change. Capture lab LCP, INP, and CLS (plus supporting timings you report) on mobile and desktop for the URLs in scope. Store the run dates so the before/after is not a memory test.
Keep a schedule after you ship. Daily or a few times per week on high-value pages, less often on long-tail templates, matching the priority model in how to schedule PageSpeed monitoring frequency.
Set budgets and alerts on lab vitals. Use thresholds from a shared performance budget template so a regression during the CrUX wait still notifies someone, even if field data has not moved yet.
Read field data once a week. Check PageSpeed Insights or Search Console, note the collection period, and compare direction of travel rather than day-to-day noise.
Document the lag in client language. One sentence in the retainer report ("Field CrUX remains a 28-day rolling average; lab trends below are same-week verification") saves a meeting.

Apogee Watcher runs that split for multi-site teams: scheduled PageSpeed Insights-backed lab tests across many sites, CrUX field numbers when Google returns them beside the lab result, budgets and alerts while you wait, and multi-tenant organisations so agencies are not pasting PageSpeed Insights links into spreadsheets. We do not replace first-party RUM. We do not invent a faster CrUX. We give you a repeatable lab clock next to the field clock Google already publishes, layered onto the SEO and observability tools you already use.

What to tell clients when CrUX has not updated yet

Stakeholders rarely want a lecture on aggregation windows. They want to know whether the invoice bought a real improvement. Use a short script in email and in the monthly review. Do not put lab dates and field screenshots on the same slide without labels.

What we fixed: name the change (script removed, image pipeline, CDN rule) and the URLs.
What lab shows now: before/after on the same strategy (mobile/desktop), with dates.
What field will do next: CrUX and Search Console update from a 28-day rolling average of real Chrome users; expect gradual movement over weeks, not an overnight flip.
What we watch meanwhile: scheduled lab budgets and alerts so regressions do not hide behind the lag.
What "done" means: lab stable in budget for several days, then field p75 entering Good (or the agreed band) on the URLs or origin in scope.

Avoid promising a specific Search Console colour by a calendar date unless traffic is huge and the fix is clear. Prefer ranges ("we expect clearer field movement after two to three weeks of post-fix traffic") and show the collection period when tools expose it. If origin status stays poor while one landing page is excellent in lab, explain template mix rather than declaring CrUX broken.

FAQ

When does CrUX update after I fix Core Web Vitals?

The CrUX views in PageSpeed Insights and the CrUX API refresh often (typically daily for the rolling window, with a short processing lag). The number you see is still an aggregate of about 28 days of Chrome experiences, so your fix enters the published p75 gradually as older sessions age out. Plan client expectations in weeks, not hours.

Why is CrUX different from my Lighthouse score after a deployment?

Lighthouse (lab) measures a controlled run you triggered. CrUX (field) averages real users over a sliding 28-day window. Both can be correct at once: lab proves the new code path, field still includes pre-fix traffic. For shorter windows and session segments, see how first-party RUM sits beside CrUX in synthetic versus real user monitoring.

Is Core Web Vitals in Search Console the same 28-day rolling average?

Search Console's Core Web Vitals report is based on CrUX field data, so it inherits the same rolling-window behaviour and eligibility limits. Treat it as a lagging SEO view, not a same-day deploy dashboard. Use scheduled lab monitoring for immediate verification.

How long until field data fully reflects my change?

A full replacement of the window takes on the order of 28 days of post-fix traffic in the aggregate, though large improvements on high-traffic URLs can show direction earlier. Low-traffic URLs may move slowly or lack URL-level CrUX entirely. Keep lab history so you are not blind during that period.

Should agencies wait for CrUX before closing a performance ticket?

Close the engineering ticket when lab verification and release criteria are met, then keep a separate field-watch item until CrUX or Search Console moves into the agreed band. Mixing those two definitions of "done" creates false reopenings in week one. Budgets and alerts on scheduled tests keep the watch honest without daily manual PageSpeed Insights checks.

On Monday, open the priority URL list for the account that shipped last week. Record lab LCP, INP, and CLS from the latest scheduled run beside CrUX or Search Console status, and note the collection period dates when they are available. One line per row is enough: lab improved, field still lagging, or field data missing. If you manage many client sites and need that history on a schedule, start a free trial of Apogee Watcher or run a free domain PageSpeed check on one money URL first. Set budgets on the pages that pay the bills, review field collection periods weekly, and keep the 28-day rolling-average sentence in the client report until the amber screenshot turns green.

When to Use Synthetic vs Real User Monitoring for Performance

Sun, 28 Jun 2026 08:53:55 +0000

Performance monitoring conversations often collapse two different questions into one: "Are we fast in a controlled test?" and "Are we fast for real visitors?" Synthetic monitoring answers the first; real user monitoring (RUM) answers the second. Teams that pick only one layer usually discover the gap after a deploy, when lab scores look fine but conversion drops on mobile, or when CrUX turns red a week later. What follows is a practical split for web teams and agencies: what each method measures, when each is worth the operational cost, and how scheduled PageSpeed monitoring with CrUX context fits beside first-party RUM without forcing a rip-and-replace.

What is synthetic monitoring for web performance?

Synthetic monitoring runs automated tests against URLs you choose, on a schedule you control, in a lab environment, loading each page with a fixed device profile, simulated network, and throttled CPU (for example Lighthouse mobile emulation through PageSpeed Insights) so results stay comparable run to run.

Typical outputs include:

Core Web Vitals from the lab run (LCP, INP, CLS where Lighthouse reports them).
Lighthouse Performance score and supporting timings (FCP, TBT, Speed Index).
Diagnostics and opportunities (render-blocking resources, image sizing, third-party cost).
Chrome User Experience Report (CrUX) percentiles when Google publishes field data for that URL and strategy.

Synthetic monitoring is not a one-off PSI paste into a browser tab. It is the same class of measurement, repeated and stored so you can trend, alert, and report. Our PageSpeed Insights vs automated monitoring guide explains why spot checks fail once you manage more than a handful of URLs. Agencies use synthetic schedules to cover client portfolios (homepage, pricing, lead forms, checkout paths, and campaign landers), usually on both mobile and desktop strategies.

What is real user monitoring (RUM)?

Real user monitoring collects performance data from actual browser sessions on your site. A JavaScript snippet, or tag manager injection, records timings, navigation, and often custom attributes (logged-in state, plan tier, locale) as users browse, which is why RUM reflects real networks, devices, cache states, ad blockers, and consent banners rather than a fixed lab profile.

First-party RUM products (PageVitals, DebugBear, SpeedCurve, Datadog RUM, and others) let you:

Segment by page, device, geography, and custom tags.
See distributions and percentiles from your traffic, not only Google's aggregate.
Monitor routes CrUX rarely covers well (authenticated app shells, low-volume templates).
Tie performance to business events when you connect analytics or product data.

That traffic mix is also why RUM is harder to compare week to week unless you control for seasonality and campaigns. For metric definitions shared by both lab and field programmes, start with What Are Core Web Vitals? and LCP, INP, and CLS explained.

CrUX vs first-party RUM: both are field data, but not the same thing

Teams comparing RUM vs synthetic monitoring sometimes treat CrUX as "free RUM," yet it is field data without session-level detail, and that distinction matters when you choose tooling or write a client report.

Source	What it is	Strength	Limit
CrUX	Google's aggregated Chrome experience for URLs with enough traffic	Aligns with Search Console and SEO reporting; no snippet required	Rolling window; URL-level; limited segmentation
First-party RUM	Your snippet on your origin	Session paths, custom tags, logged-in views	Consent, tag governance, maintenance per site
Synthetic lab	Scheduled Lighthouse-style runs	Same-day, repeatable, works on staging	Simulated users, not real cache or ad mix

PageSpeed Insights and many monitoring tools show CrUX beside lab results, which helps public marketing URLs, but that pairing does not replace RUM when stakeholders ask what paying customers on 4G in Germany experience on a specific checkout step. Mobile vs desktop Core Web Vitals monitoring matters here as well: CrUX and lab both split by strategy, yet RUM segmentation is where device and connection reality show up for product decisions.

Synthetic vs RUM: comparison for web teams

Question	Synthetic (scheduled lab)	First-party RUM
Needs a script on the site?	No	Yes
Works on staging / pre-release URLs?	Yes	Usually no (no real traffic)
Comparable numbers every run?	Yes	Depends on traffic mix
Catches deploy regressions same day?	Yes, if scheduled	Yes, with enough sessions
Good for SEO / CrUX alignment?	Lab + CrUX in PSI output	CrUX separate; RUM is your own dataset
Portfolio scale without per-site snippets?	Favourable for agencies	Harder (consent and client approvals)
Multistep flows (checkout, signup)?	Per-URL unless tool supports journeys	Strong when tagged correctly

Neither approach wins outright because they answer different risk questions: synthetic shows whether yesterday's release broke lab thresholds on URLs you list, while RUM shows whether real users felt it across segments you care about.

When synthetic monitoring is the right choice

Choose synthetic as your primary web performance layer when you manage many sites or URLs and need one schedule, one history store, and one alert policy without installing tags on every client origin. That is the common agency constraint on marketing sites, brochureware, and public app URLs where the client will not approve another analytics script.

Synthetic also fits when you need repeatable baselines before and after a change. Lab runs on the same URL, strategy, and daypart make comparisons honest, whereas field data drifts when traffic mix shifts. The same logic applies to low-traffic or new pages where CrUX may show "no data" for months while scheduled lab runs still return LCP, INP, and CLS every time.

Use synthetic for staging, preview, or password-protected builds before production, because RUM cannot run where users do not visit yet. Pair schedules with performance budgets and alerts when you need a steady measurement source, and with portfolio reporting when clients want trend lines instead of a PDF assembled from manual PSI tabs; Automated vs manual PageSpeed testing shows the time cost when that layer is missing. Synthetic monitoring still does not replace backend APM, error tracking, or session replay: it measures web URLs in the browser lab, plus CrUX where published, not API latency inside your cluster.

When real user monitoring is the better fit

Choose first-party RUM when authenticated experiences dominate the product. Dashboards, account settings, and checkout after login often lack stable CrUX samples, and RUM with custom tags is how you prove INP on those routes. The same applies when stakeholders require segment-level proof by plan tier, locale, experiment bucket, or campaign source, because CrUX will not break down your traffic that way.

RUM also belongs in the stack when you already operate observability tooling and need web vitals beside traces and errors, when CI/CD or feature flags need session-level validation after release, or when multistep journeys must be measured as flows rather than isolated URLs. Legal and client approval for another script varies by estate, and if RUM is already installed you can add synthetic for URLs RUM under-samples or for pre-production checks, while teams with synthetic schedules add RUM where lab and CrUX disagree with support tickets or conversion data.

How agencies combine synthetic and RUM across client portfolios

Agencies rarely get a single answer across thirty clients, but a workable default is to run scheduled synthetic on mobile and desktop for public marketing and lead-gen URLs, read CrUX from the same test results, and keep budgets and alerts in one place without a snippet on every domain. For flagship SaaS or ecommerce clients with RUM already installed, keep their RUM vendor for logged-in app routes and use synthetic for the URLs the retainer covers and for prospects during performance audit outreach; when clients refuse third-party scripts, synthetic plus CrUX is often the entire programme, so say that explicitly in proposals rather than implying session replay is included.

In client reporting, separate slides for lab trends on priority URLs and for RUM segment summaries from the analytics team. Blending both into one green chart invites arguments about methodology. For tool selection by client shape, see comparing PageSpeed monitoring tools for agencies and PageVitals vs Apogee Watcher when RUM and CI/CD are part of the brief. SaaS product teams face a similar split at single-company scale; our SaaS performance monitoring guide covers URL priorities without repeating the full decision tree here.

How scheduled PageSpeed monitoring fits beside RUM vendors

Apogee Watcher is built for scheduled synthetic monitoring across many sites: PageSpeed Insights-backed lab runs, CrUX when Google returns field data, vitals and optional FCP/TBT budgets, portfolio alerts, and multi-tenant organisations for agencies. We do not ship first-party RUM; we sit beside RUM, APM, and Lighthouse CI gates rather than replacing them, so when a client needs session-level RUM, PageVitals, DebugBear, or an observability vendor still belongs in the stack.

Watcher is often the better primary monitor when you run many client domains under one subscription without per-site RUM rollout, when automated page discovery should keep new templates on the schedule without spreadsheet maintenance, when retainers promise ongoing CWV oversight on public URLs rather than full product instrumentation, or when you want prospecting and free evaluation via the domain PageSpeed check before a client signs. Configure mobile and desktop strategies per URL, set budgets, route alerts, and review history in the app, and use RUM elsewhere when the question requires your traffic, your tags, and your logged-in routes.

FAQ

What is the difference between RUM and synthetic monitoring?

Synthetic monitoring runs controlled lab tests on chosen URLs on a schedule. RUM records performance from real user sessions in the browser, usually via a script you install. Synthetic is repeatable and works without site traffic; RUM reflects actual devices, networks, and behaviour, which is why most mature teams treat the two as complementary rather than interchangeable.

Is CrUX the same as RUM?

No. CrUX is Google's aggregated field dataset for URLs with sufficient Chrome traffic, while RUM is first-party data you collect from your visitors. Both describe real loads in the field sense, but CrUX is not session-level RUM and cannot replace custom segmentation on your origin.

Should I use synthetic or RUM for Core Web Vitals?

Use both when you can. Synthetic and CrUX (via scheduled PSI runs) cover public URLs, staging, and low-traffic pages; first-party RUM covers segmented and authenticated experiences CrUX does not explain. SEO and client reporting often lean on CrUX, while product teams often lean on RUM for route-level proof.

Do agencies need RUM on every client site?

No. Many retainers cover public marketing and key templates where synthetic plus CrUX is enough, and you add RUM when the contract includes logged-in app routes, the client already owns a RUM tool, or stakeholders require session-level segmentation that CrUX cannot supply.

Can synthetic monitoring replace RUM?

Not fully. Synthetic answers whether lab thresholds breached on listed URLs, while RUM answers what users experienced broken down by segment, so use synthetic for portfolio scale and pre-release checks and RUM where traffic truth and custom tags matter.

Does Apogee Watcher include RUM?

No. Watcher schedules PageSpeed lab tests and shows CrUX where available, and you should layer it with your RUM or observability vendor when you need first-party session data on authenticated or heavily segmented routes.

How often should synthetic tests run compared to RUM sampling?

Synthetic frequency is a schedule you set (daily, weekly, or higher on risky URLs), while RUM sampling is continuous or rate-limited by your vendor. Match synthetic cadence to release risk, use RUM for always-on field truth where installed, and see test frequency and priority across a portfolio for scheduling patterns across many sites.

Pick synthetic when you need repeatable lab coverage at portfolio scale without a snippet on every domain, and RUM when session segments and authenticated routes drive decisions. Most mature stacks use both, with clear owners for each signal, rather than debating which single tool should own performance end to end.

Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets across your sites, or run a free domain PageSpeed check to baseline a URL before you add RUM or expand monitoring.

Apogee Watcher vs PostHog Web Vitals: Synthetic PageSpeed Monitoring and Product Analytics Compared

Mon, 06 Apr 2026 12:09:27 +0000

Core Web Vitals show up in two different places. One is real users: metrics from the browser, fed by an analytics SDK. The other is scheduled tests: Google’s PageSpeed machinery runs on a URL you choose, on a cadence you set.

PostHog is the first kind for performance. Its Web Vitals live under Web Analytics and use the same posthog-js SDK as the rest of product analytics. Apogee Watcher is the second kind: multi-tenant PageSpeed monitoring on the PageSpeed Insights API—Lighthouse lab data plus CrUX where Google publishes it—for teams covering many sites without putting a script on every domain.

PostHog is a strong product stack (flags, replay, experiments, warehouse analytics). We are not building that. PostHog’s Web Vitals module also does not replace synthetic monitoring for sites you never instrument, and it does not include Watcher’s automated discovery, performance budgets, or agency RBAC by default. The decision is which problem you are solving first—and whether you need both.

What PostHog Web Vitals actually is

PostHog’s docs describe Web Vitals autocapture for FCP, LCP, INP, and CLS via Google’s web-vitals library. You turn on Web vitals autocapture in project settings (separate from generic autocapture) and run posthog-js v1.141.2 or newer. Events are named $web_vitals, with properties such as $web_vitals_LCP_value per metric.

The UI is built for analysts: Web Analytics → Web Vitals gives trends, the same filters as the rest of Web Analytics, and a URL table in good / needs improvement / poor buckets against PostHog’s thresholds (same bands as web.dev). You can view p75, p90, or p99; PostHog recommends p90 as a balance between signal and noise. The toolbar shows vitals for the page you are on plus history for that page—handy while you debug in product.

That scope is intentional: PostHog gives you Core Web Vitals metrics and trends for product analytics—it does not replicate a full PageSpeed Insights or Lighthouse lab report. You do not get the complete Lighthouse output from a PSI-style run: audit categories, opportunities, diagnostics, performance score breakdown, and the rest of the structured result you would see after calling the PageSpeed Insights API. For that depth you need a synthetic lab run (or another tool that runs Lighthouse end to end), not $web_vitals events alone.

Operationally, the SDK batches vitals (a few seconds’ flush by default). You can sample $web_vitals in before_send if billable events are a worry. PostHog suggests roughly 30 $web_vitals events per 100 $pageview events on average; vitals bill like any other event—see pricing.

Cookieless mode. With PostHog’s cookieless tracking (cookieless_mode: 'always', or the cookieless branch of on_reject), posthog-js does not send usable $web_vitals data: each vitals payload needs session and window IDs, and in these modes the usual session path is not there, so metrics are dropped. If you run banner-free always cookieless, do not expect a filled Web Vitals dashboard from PostHog alone—you give up that slice of analytics depth on purpose. SDK details change; check PostHog’s docs when you upgrade.

You only measure visitors who load the snippet and whose sessions allow vitals (consent, ad blockers, cookieless settings, whether the page ran long enough to emit metrics). That fits your product when capture is on. It does not cover dozens of client domains you never instrument, or a prospect URL before you have access.

Budgets and email alerts: how much setup each tool expects

PostHog has no monitoring-style “CWV budget” object—no per-URL LCP/INP/CLS cap with a built-in schedule and cooldown the way ops teams mean “budget.” You explore vitals in the Web Vitals UI; alerts hook onto trends insights in Product Analytics.

To get “email when this metric crosses a line,” you build or open a trend that plots the right series (often from $web_vitals fields), pick the series the alert watches, set a fixed or relative threshold, choose a check interval (hourly to monthly), and add email, Slack, or webhooks. Goal lines on the chart can match the threshold, but you are still in the insights product—not “add a budget for this URL” in one step. Someone has to keep those insights valid when events, filters, or properties change, and to align percentiles and sampling with what you are alerting on.

Watcher puts performance budgets and email next to scheduled PageSpeed tests for the org, site, or page you already track—no trend model first. Cooldowns are there to reduce alert noise for ops, not for funnel review. That is synthetic + CrUX only; it does not replace PostHog alerts on signups, revenue, or anything non-PageSpeed.

Teams deep in PostHog often fine-tune vitals insights and alerts and are right to. If the job is “keep client sites inside CWV limits with little glue,” a monitoring product usually means fewer steps.

What Apogee Watcher optimises for

Apogee Watcher is monitoring-first, not analytics-first. We run scheduled PageSpeed tests via Google’s API, store history per organisation, site, and page, and surface lab and CrUX together so you can see both “what Lighthouse saw” and “what Chrome users experienced at scale” when CrUX has data for that URL. You do not deploy our code on your clients’ sites to get baseline monitoring—we hit public URLs from Google’s test infrastructure.

That design choice matters for agencies:

Add staging or production URLs even when marketing controls the tag manager and will not add another script.
Organisations, sites, pages, and Admin / Manager / Viewer roles match how agencies staff work—not one analytics property per product.
Sitemap and HTML crawl so new templates and landers are not stuck behind a manual URL list.
Budgets and alerts aimed at “tell us before the client’s CWV drifts for a week,” not funnel charts.
Leads Management for new business: prospect URL, one-page reports, time-limited share links, score-band outreach—revenue workflows, not session analytics.

We do not ship a full product analytics stack, session replay, or feature flags. If you need those, use a tool built for them—often PostHog.

Side-by-side: where the overlap ends

Topic	PostHog (Web Vitals)	Apogee Watcher
Primary job	Product analytics OS; Web Vitals are real-user metrics from the browser	Synthetic PageSpeed monitoring + CrUX in results
Instrumentation	Requires `posthog-js` on the site	No script on monitored sites
Metrics	FCP, LCP, INP, CLS from real sessions (`$web_vitals`) when capture runs — not a full Lighthouse/PSI audit payload	Lighthouse lab + CrUX (where available) via PSI (full Lighthouse context per scheduled run)
Cookieless analytics	With `always` (and cookieless paths without session IDs), `$web_vitals` does not populate—see Cookieless mode above	No snippet; tests do not use PostHog session state
Best for	“How do my users experience my app?”	“How are these URLs doing on a schedule—and across many clients?”
Multi-site agency	Analytics projects and teams—not Watcher’s org/site/page model	Multi-tenant orgs, roles, discovery, budgets
Budgets & email alerts	Insight-based—build trends from `$web_vitals`, attach [alerts](https://posthog.com/docs/alerts) with thresholds, frequency, destinations; maintain as analytics evolves	Monitoring-native—performance budgets and email alerts tied to scheduled tests; no separate insight to curate first
Extras	Flags, replay, experiments, cohorts, warehouse pipelines	PDF-style reporting direction, Leads prospecting workflows
Cost shape	Event-based (vitals count toward event quotas)	Plan-based subscription; PSI quota bundled—verify [pricing](/pricing)

Use the table as a decision grid, not a spec sheet. Both products change; verify details on each vendor’s site before you buy.

When PostHog is the better primary choice

Choose PostHog when you own the app, already want product analytics, and need real-user vitals next to releases, experiments, and segments. If the question is “did that React change hurt INP for paying customers on Safari?”, you want RUM inside analytics—not only a nightly PSI run.

Feature flags and experiments sit next to Web Vitals, so you can tie score moves to what shipped. We do not replace that layer.

When Apogee Watcher is the better primary choice

Choose Watcher when synthetic coverage and agency workflow matter more than in-app events:

You watch many client or third-party sites where you will not (or cannot) deploy PostHog for a baseline.
You want scheduled checks, regressions, and budgets even when traffic is quiet this week.
Automated discovery matters because CMSs and URL lists change constantly.
You sell retainers and need client-ready reporting plus role separation (internal vs customer).

For the upgrade story from manual checks, see PageSpeed Insights vs Automated Monitoring. For setup at scale, How to Set Up Automated PageSpeed Monitoring for Multiple Sites tracks the same workflow we care about.

The complementary stack (layer, do not replace)

For many agencies the practical setup is both: PostHog (or similar) for behaviour and real-user vitals on sites you control, plus Watcher for multi-site synthetic monitoring, CrUX where Google provides it, and prospecting workflows. Different questions:

PostHog Web Vitals — What did users experience on routes we instrumented?
Watcher — Are our URLs still inside budget—what did lab + CrUX show on the last scheduled run?

RUM alone can miss pre-launch or zero-traffic URLs. Synthetic alone can miss logged-in or heavy-JS interaction pain. Together they cover more ground.

If you already use PostHog, what does Watcher add?

You already have $web_vitals, charts, and optional trend alerts—except in cookieless setups where vitals do not fire (see above). Watcher does not copy flags, replay, or experiments. It adds:

CWV signals when PostHog cannot send vitals. Cookieless always (or the no-session cookieless branch) leaves the Web Vitals view empty. Watcher still runs scheduled PSI + CrUX on the URLs you care about—independent of cookies, consent, or snippet load.

Scores without traffic. PSI can run on a timetable when visits are rare, the page is new, or the build is on staging without production tagging. PostHog needs visitors; Watcher needs a public URL.

Sites with no PostHog. Retainers, handovers, marketing-owned stacks, or prospects before contract: you still get lab + CrUX from Google without another analytics install per domain.

Portfolio shape. Orgs, sites, pages, Admin / Manager / Viewer, and sitemap + crawl discovery match “many clients, many URLs,” not one analytics project per product.

Monitoring alerts. Thresholds and email on test results and cooldowns, without building a trend per metric (see Budgets and email alerts above).

Sales workflows. Leads Management—prospect URL, one-page report, share link, score-band outreach—where PageSpeed is part of new business, not product analytics.

Two lenses on one site. On your own marketing site you can compare browser RUM with scheduled lab + CrUX. When they disagree, that is often lab vs field vs session—useful, not contradictory.

Watcher is not a second analytics product. It adds external monitoring, agency access control, and stored synthetic history next to what PostHog already does.

Limitations we will not sugar-coat

Watcher is not session replay, funnels, or feature flags.

PostHog Web Vitals are event streams from the browser, not a full PSI/Lighthouse audit (see What PostHog Web Vitals actually is). Watcher’s stored PSI runs include full Lighthouse context on a schedule—lab plus CrUX—when you need that bundle. In cookieless PostHog setups where *$web_vitals never lands**, you have no CWV series in PostHog at all—**synthetic monitoring** (here or elsewhere) is how you keep scores without changing your privacy settings.

Cookieless PostHog and Watcher work side by side: your analytics privacy choice does not block server-side PageSpeed tests.

CrUX needs enough real Chrome traffic; quiet URLs may show no field data. RUM, CrUX, and lab can disagree—that is normal.

Bottom line

PostHog’s Web Vitals docs cover real-user vitals for teams on the SDK. Watcher covers scheduled synthetic + CrUX for teams running many URLs and client-facing workflows. Decide on coverage (script or not), question (users vs URLs), and org model (analytics project vs agency portfolio)—then use one tool or both.

If Watcher matches how you work, check pricing and features for solo operators and agencies—including what is live for Leads Management—before you assume every seat gets full prospecting access.

FAQs

Is Apogee Watcher a PostHog alternative?
No. PostHog is product analytics; Web Vitals are one part. Watcher is PageSpeed / CWV monitoring across portfolios. Use neither, one, or both.

Does PostHog replace scheduled Lighthouse monitoring?
No for URLs you never instrument, or environments with no traffic. Synthetic runs still matter.

Does Watcher replace real-user vitals?
No. RUM captures post-load behaviour (SPAs, logged-in flows). CrUX helps at URL level when Google has data; it is not full RUM.