Your field data and Google's will disagree, correctly

Firefox 144 added interaction measurement in October 2025. Safari 26.2 shipped Largest Contentful Paint and the Event Timing API on 12 December 2025. For the first time you can measure real user performance across every major browser, and that is going to make your data disagree with Google's.

Both sets of numbers will be right. Understanding why is the difference between a useful performance programme and an argument about tooling.

Where Google's numbers come from

The Chrome User Experience Report is built from Chrome users who have opted in to usage statistics reporting. Chrome only. It always has been, and there is no path where Safari or Firefox start feeding Google's dataset.

That is the dataset behind the Core Web Vitals report in Search Console, behind PageSpeed Insights field data, and behind the page experience signal itself. Google grades Chrome because Chrome is what Google can see.

Your real user monitoring, if you have it, sees whoever visits. In Australia that skew matters more than most places, because iPhone share is high and Safari is over half of mobile browsing in comparable markets. If a large share of your traffic is on Safari, Google is grading a minority of your audience.

What each browser can and cannot measure

The support picture is uneven, and knowing the specific gaps stops you chasing ghosts.

Firefox has supported LCP since January 2024, and added interaction measurement through a per-interaction identifier in Firefox 144, October 2025. It also gained the Scheduler API, including the yield method, in August 2025, which is the cleanest way to break up long tasks.

Safari 26.2 shipped LCP and Event Timing in December 2025. The interaction numbers it produces still have bugs, and it will sometimes report values that are clearly unreasonable. Treat Safari interaction data as directional until it settles, and check the distribution rather than the percentile.

Neither Firefox nor Safari has plans for Cumulative Layout Shift. So layout stability remains a Chrome-only measurement, which means visual instability on iPhone is something you have to catch through session recording or manual testing, not through a metric.

The mistake to avoid

The instinct when two data sources disagree is to declare one broken and stop looking. Do not.

If your real user monitoring shows a worse LCP than Google's dataset, the most likely explanation is that your non-Chrome users are having a worse time, and Chrome-only data was hiding it. Safari handles some things differently, including image decoding behaviour and how certain font loading strategies resolve, and older iPhones sit in the field far longer than equivalent Android devices because they keep receiving updates.

If your monitoring shows a better result, look at device and connection mix. Google's dataset includes people on slow connections and old hardware in proportion to real Chrome usage. A setup that only fires after a consent banner is accepted, or that fails to load on the slowest connections, systematically drops your worst experiences. That is survivorship bias built into your instrumentation, and it flatters you.

Two changes that broke reports quietly

The Effective Connection Type dimension was retired from the BigQuery dataset and replaced by Round Trip Time. If you had a report segmenting by 4G and 3G, it stopped producing data rather than erroring. Round Trip Time is the better dimension anyway, because it is a measured number rather than a bucket guess, and it now arrives with a 75th percentile and histograms.

The dashboard many teams built their monthly reporting on, the Looker Studio connector, was deprecated at the end of November 2025. The October 2025 dataset was the last one it received. Any dashboard still pointing at it has been showing the same numbers for eight months.

While you are in there, the January 2025 dataset added LCP image subparts and LCP resource type. That is the most useful addition in years, because it tells you whether your LCP problem is server time, resource load delay, resource load duration or render delay, without you having to instrument it yourself.

How to report this to a board

Use both, and label them properly.

Google's dataset is your compliance number. It is what Google sees, what feeds the page experience signal, and what you point at when someone asks whether your site passes.

Your own monitoring is your truth number. It covers your whole audience, updates immediately rather than on a 28-day rolling window, and can be segmented by page template, campaign source and device.

The 28-day window is worth saying out loud, because it catches people. Ship a fix today and Google's dataset will not fully reflect it for four weeks, since every day of the old experience stays in the window until it ages out. Teams panic in week two and start changing things again on top of a fix that was already working.

Two datasets that disagree is not a problem to resolve. It is two questions being answered.