Google flagged a measurement-side regression in the June 9 CrUX release, mostly on Android. Here is how to tell whether the drop is you or the dataset before you ship a fix.
Key Takeaways
- ✓The June 9, 2026 CrUX release shows mobile pass-rate dips of 3 to 8 points on sites that made no changes; desktop is roughly flat. See the official CrUX release notes.
- ✓Google acknowledged the pattern directly: 'We see a regression in pass rates this month, mostly on Android. We are investigating and have nothing definitive to share yet.'
- ✓Cross-check by segmenting CrUX by device, comparing against your own RUM, and checking whether the drop is uniform across templates. Uniform-across-templates plus desktop-steady points to a measurement-side event.
- ✓Do not ship panic fixes. Wait for the July 14 CrUX release for the June-data update, and reread your last two months of change logs to rule out an internal deploy that lined up with the window.
The symptom you noticed
If you opened Search Console in the second half of June 2026 and saw your mobile Core Web Vitals pass rate drop across URLs you have not touched, you are not alone. Sites we monitor showed mobile pass-rate dips of 3 to 8 percentage points in the June 9 CrUX release, on origins where nothing had changed on the site itself. Desktop held roughly flat over the same window. The pattern is Android-heavy and consistent enough to look like a measurement-side event, not a site-side one.
What Google itself said
On June 9, 2026, the Chrome team acknowledged the pattern in the official CrUX release notes with this line: 'We see a regression in pass rates this month, mostly on Android. We are investigating and have nothing definitive to share yet.'
That is unusually direct language from the CrUX team. It matters because it tells you that the drop is at least partly a change in how the data is being collected, aggregated, or sampled, not a change in how your site is performing. If Google had ruled out a measurement issue, they would have said so.
How to tell if the drop is your site or the dataset
You cannot answer this from Search Console alone. You need three cross-checks.
Segment your CrUX data by device. Pull CrUX (via PageSpeed Insights, Search Console, or the CrUX API) for desktop and mobile separately. If desktop held steady over the May-to-June window and mobile dropped, that is a strong signal of a device-side measurement change, because your codebase and infrastructure are shared across both.
Compare against your own real user monitoring. If you have RUM (via a tool like DebugBear, Vercel, or a custom Web Vitals script), pull the same date range. If your RUM shows LCP, INP, and CLS holding steady on Android over exactly the window CrUX shows dropping, the drop is in the CrUX aggregation, not in user experience. If your RUM also shows a drop, it is a real regression and you have work to do. Our glossary entry on field data vs lab data walks through why these two data sources can disagree.
Check whether the drop is uniform across pages. A real site-side regression usually affects a subset of templates (checkout, product, homepage). A measurement-side change usually affects all templates on the same device evenly. If every template dropped by roughly the same amount on Android and nothing dropped on desktop, that is the measurement pattern.
Context: baseline pass rates were already fragile
Even before this regression, only 55.9% of origins in the May 2026 CrUX dataset were passing all three Core Web Vitals. Pass rates have been improving year over year, but the majority of the web still fails. A 3 to 8 point drop on top of a 55.9% baseline is meaningful, but it also means most origins that dropped are moving from one side of the pass line to the other, not going from healthy to broken.
What to do this week, and not do
Do not ship panic fixes. Rolling out a JavaScript change or an image optimization pass in response to a measurement-side regression will introduce real bugs while doing nothing to move the CrUX number, because the number was not driven by your site in the first place.
Do these five things instead:
- Document your baseline. Screenshot Search Console and export your CrUX API results for early June, so you have a fixed reference.
- Set an alert. Watch the July 14 CrUX release for the June-data update, which is the next signal about whether the regression persists.
- Run your own audit. A single WebPageTest run on your top three templates from a mid-tier Android profile tells you whether real performance changed. Save the trace.
- Hold marketing. Do not spin up a 'we made the site faster' campaign that leans on a Search Console screenshot from May, because it can look bad if June's number regressed for reasons that had nothing to do with the campaign.
- Reread your last two months of change logs. Rule out an internal deploy that happens to line up with the regression window. It is rare but not impossible.
If you want a second opinion
We are running free Core Web Vitals diagnoses for sites that saw June regressions. We pull the CrUX API history for your origin, cross-check against a synthetic run, and tell you within 48 hours whether the drop looks measurement-side or site-side. Book one through our Core Web Vitals optimization service.