One checkout URL can look healthy in a blended score while mobile passes and desktop fails. Portfolio averages hide the same split. Here is how we report paired device data instead.
The account manager pasted a portfolio screenshot into Slack: average Core Web Vitals pass rate across twelve client sites was 81 percent, up three points from last month. Engineering opened the same week’s export and found checkout on one retailer at 94 on mobile and 41 on desktop, both from the same URL, both in field data. The average looked like progress; the paired rows looked like a revenue problem waiting for a marketing campaign to send desktop traffic to a route that could not convert.
Same URL, two device stories. That is normal for Core Web Vitals, not a tooling glitch. Google’s own field datasets already treat mobile and desktop as separate populations: the Chrome UX Report (CrUX) stores experiences by form factor, and Search Console’s Core Web Vitals report labels each URL group independently for mobile and desktop. The gap is not that vendors lack the split; it is that internal dashboards and client decks collapse the split back into one comforting number.
Why mobile and desktop Core Web Vitals diverge on one URL
Largest Contentful Paint often tracks different elements after responsive layout: a hero image on desktop and a text block or product tile on mobile. Interaction to Next Paint reflects touch versus pointer paths, menu density, and how much main-thread work survives on lower-end hardware. Cumulative Layout Shift spikes when ads, banners, or consent UI appear only under certain viewports. None of that shows up if you only store a single “page score” per URL.
Lab runs make the split obvious when you compare mobile and desktop emulation on the same template. Field data from CrUX does the same by form factor, which is why PageSpeed Insights shows separate rows and accepts strategy=mobile or strategy=desktop in its API. Google’s web.dev guidance on lab versus field data adds a further wrinkle: Lighthouse returns the same LCP candidate every time, while field data on one URL often spans several LCP elements depending on viewport and scroll depth. Stopping at whichever row looks better, or averaging them for a client deck, hides that variance. For metric definitions and fix paths, our LCP, INP, and CLS guide on the Watcher blog stays the reference.
Where blended scores and portfolio averages mislead
We see three patterns that produce misleading comfort in dashboards and decks.
Single-number client reports. A weekly PDF that lists one LCP or one “performance score” per URL without a form-factor column implies one experience. Sponsors assume the number covers how most users browse; in our experience mobile share is often higher on the URLs that matter, but desktop still carries high-value sessions on B2B and admin-heavy flows. Public CrUX aggregates show the same skew: mobile origin pass rates typically trail desktop by several points, so a blended headline can flatter phone-heavy sites even when mobile is the weaker side.
Portfolio rollups. Agency dashboards that average pass rates across domains treat a mobile fail on checkout and a desktop pass on a blog post as partial credit. The rollup climbs while the conversion path stays broken. We prefer worst-of or paired counts: how many priority URLs pass on both mobile and desktop, not how many pass on either. Search Console labels URL groups separately per device; a group can be Good on mobile and Need improvement on desktop. Exporting one “site health” percentage without that dimension is how an eighty-one percent portfolio average coexists with checkout at forty-one on desktop.
“Good enough” thresholds on the stronger device. Teams sometimes ship when desktop clears a budget while mobile INP stays red because desktop was the default Lighthouse profile in continuous integration. The deploy log shows green; support tickets mention “laggy on phone.” A related trap is treating PageSpeed Insights origin-level field data as proof that a specific URL is fine: when URL-level CrUX samples are thin, PSI falls back to origin aggregates, which can mask a single high-traffic template that fails on one form factor only.
Each pattern shares the same fix: store and show mobile and desktop as separate series for the same URL, then alert on the weaker side.
How we report paired device data to clients and internally
We stopped leading with averages in QBR slides. The first table for priority URLs lists mobile LCP, INP, and CLS beside desktop values for the same route, with a column for “both pass” rather than “either pass.” When one side lacks field data, we label it lab-only and do not merge it into a blended pass/fail. For alerts, device-specific thresholds beat a single budget line: a regression that hits mobile INP on checkout triggers the same channel as a desktop LCP fail on the homepage, but the message names the form factor so triage does not waste a day reproducing on the wrong profile.
Internal stand-ups that read “mobile fail / desktop pass” in the subject line have saved us from closing tickets too early, because the split is visible before anyone opens the chart. When a client asks for one headline number, we give them a paired summary: “ten of twelve money URLs pass on both mobile and desktop; two fail on mobile only.” That sentence is less flattering than an eighty-one percent average, and it is the one that gets engineering budget for the checkout script audit. Schedules, budgets, and portfolio views are in mobile versus desktop Core Web Vitals monitoring on the Watcher blog; Watcher holds the checklist, while Hashnode holds the reporting argument.
What to change in monitoring this week
If your stack stores one row per URL, add form factor to the grain before the next client send. Re-run baselines on five conversion URLs with mobile and desktop explicitly selected in PageSpeed Insights or your monitoring product, and note where field data exists for each. When PSI shows origin-level field data only, tag those rows as origin fallback so nobody mistakes them for URL-level proof on both devices. Rewrite one alert policy so a mobile-only breach on a tagged “money URL” cannot be drowned out by desktop green scores on the same path, and add a “both pass” metric for priority tiers if portfolio reporting is automated; the first time that metric drops while the average rises, you will know the blended number was hiding a split.
Next step
Pick one checkout or lead-form URL and publish a paired mobile/desktop baseline internally before the next client-facing report goes out. Use the mobile and desktop monitoring guide for schedules and budgets, and the LCP, INP, and CLS explainer when someone asks what the columns mean. Two device stories on one URL are expected; one averaged story is the number that usually costs you the argument.
Originally published on Hashnode.