In December 2025, Safari 26.2 started exposing the Largest Contentful Paint and Event Timing APIs through the Performance API. For the first time, real Safari sessions could report LCP and INP. Before that, WebKit simply did not emit the entries that JavaScript needs to observe those metrics, which meant that in every RUM tool and every quarterly performance review, Safari users were a blank.
Eight months on, most iPhones have updated. The blank is filling in. And a lot of eCommerce teams are about to discover that the numbers they have been reporting to their executives described only a slice of their total traffic.
Why is this a bigger deal for US retail than for anyone else?
Globally, Safari is around a quarter of mobile browsing. In the United States it is the majority: 54.69% of US mobile browsing runs on Safari, against 38.18% for Chrome, per StatCounter data compiled in May 2026. The US is the one large market where Chrome does not lead on mobile.
And the reality is actually more lopsided than that number suggests. As Shopify’s performance team pointed out, every browser on iOS runs on WebKit underneath: Chrome on an iPhone, the in-app browser in Instagram, the one in Facebook. All of it was invisible to LCP and INP reporting. For a US direct-to-consumer brand where mobile is the majority of sessions and social is a meaningful acquisition channel, the unmeasured share of traffic was not a rounding error. It was the core of the business.
Shopify’s guidance on the change was blunt about the implication: “Do not rely on CrUX, Pagespeed Insights, etc., to be your source of truth anymore. Treat RUM as the source of truth for user experience.”
Is this a short-term or temporary problem?
Here’s the wrinkle that makes this a durable problem rather than a temporary one:
Safari can now report these metrics to your own tooling. But the Chrome User Experience Report (CrUX) remains Chrome-only, and Google has been clear it is staying that way. CrUX is what powers the field data panel in PageSpeed Insights and the Core Web Vitals report in Search Console. Which means the two dashboards most eCommerce teams check are still describing a Chrome-only sample of your audience, and always will.
So the gap is now permanent and structural. Your first-party RUM can see everyone. Google’s public tools see Chrome. If those two sources disagree, the RUM data is the source that actually sees all of your customers.
This changes what “we passed Core Web Vitals” means. Passing in Search Console means you passed for Chrome users. That’s a ranking signal worth having, but it shouldn’t be confused for a comprehensive statement about shopper experience.
What should I expect from my Core Web Vitals data moving forward?
Shopify’s team, working across a very large storefront population, set expectations this way: Sample sizes will rise, which is objectively good—more data leads to tighter percentiles and higher confidence rates. LCP will shift, though not predictably in one direction. Early reports have gone both ways. INP is the wild card, because it depends far more on how your JavaScript handles events than on which engine renders the page.
That last point is worth sitting with. INP is where third-party code does its damage. If you run thirty or more tags and a chunk of your traffic has been invisible to interaction measurement until now, Safari INP data will not introduce a new problem. It will reveal one that has been costing you conversions the entire time.
What can I do about this prior to peak?
Fortunately, there’s plenty of time to get a handle over your data prior to Cyber 5. Here’s what you should do first:
- Segment your field data by browser family now. If Safari volume lands mid-November and your combined percentiles move, you want to already know whether that is a Safari effect or a real regression. Establish separate baselines while the traffic is still normal.
- Check what your current RUM solution actually covers (and if you don’t have one, get one). Browser-only beacons miss sessions: blocked scripts, abandoned loads, bot traffic misclassified as human. Yottaa built its RUM Plus solution to capture 100% of sessions with no sampling, making it one of the more powerful web insights tools on the market. But whatever you use, make sure it’s measuring real user activity across the delivery path and across browsers.
- Re-examine your INP numbers on interactive pages. Cart, checkout, filtered category pages, anything with heavy third-party JavaScript. That is where Safari data is most likely to change the picture and where the revenue consequence is highest.
- Stop quoting Search Console to your executives as a customer-experience metric. It is a search metric. Quote your field data, and know what share of sessions it represents.
The takeaway
This is a clean illustration of something that keeps happening in web performance: the tool that is free, default, and in everyone’s workflow quietly defines what the organization believes. PageSpeed Insights is free. Search Console is free. They are in every dashboard and every agency deck. And for years they encoded an assumption, that Chrome is representative, which was simply not true for US mobile retail.
The Safari change doesn’t fix that. It just makes the problem visible, and it hands teams the option of measuring properly. Some will take it. Most will keep checking Search Console, because it’s what they’ve always done.
Going into peak, the teams that win will be the ones who are willing to dive deeper to understand the truth of their digital customer experiences across all platforms and devices—not just the ones that are convenient.
Want to dive into your own real user data? Sign up for our free insights to get started today.
