While demographics and target groups differ from country to country, it’s likely you have a significant number of visitors to your website on mobile or desktop Safari. For most European and US American sites I work on, I see anywhere between 40% to 60% of traffic coming from those WebKit-based browsers.
The web performance industry has focused on Google’s Core Web Vitals (CWV) as measures of the user experience: of loading, interactivity and visual stability.
But the CWVs are only supported in Chromium-based browsers (except for Firefox, which now supports Largest Contentful Paint). That leaves us with a huge blind spot when it comes to finding and fixing performance bottlenecks in Safari.
That’s why I was super excited about Nicole Sullivan asking on Bluesky about wanting CWV in Safari.
Why not just measure CWV in Chrome?
iPhones and Macs typically have some of the fastest processors on the market. So you might reason that performance metrics are going to be slower on Android devices — and you should be optimizing for the slowest devices anyways.
Not having a set of metrics like the Core Web Vitals common to all browsers is like not trying to control the speed of the fastest half of cars on the highway.
As we often say in web performance work, “you can’t improve what you don’t measure.” So you really don’t know whether users are experiencing faster loading, less visual jank and interaction hangs without reliable metrics to measure them.
Measuring the effectiveness of a feature such as CSS containment in the field across multiple browsers is edge-casey and would be a lot easier with a common set of metrics — or at least APIs such as Element Timing or Event Timing — to work with.
And we should give customers what they want! Most of the customers I work with want to have CWV for Safari to be able to validate whether their investments in performance optimization across the entire web platform bear fruit.
“Fast” is a Matter of Definition
The Chrome team has set threshold values for the CWVs (a Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of .1 or less) that qualify as measures of “good” user experience. A webpage (or group of pages or an origin) is said to pass the Core Web Vitals assessment when three out of four values (i.e. the 75th percentile of data) for each of the metrics are in the green. While those thresholds are based on UX research, they are not set in stone.
I can imagine those thresholds changing in the future. For example, usability expert Jakob Nielsen wrote about response times in 1993:
0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
We as performance experts constantly strive to make a system feel instantaneous.
Also as Tim Kadlec pointed out in his keynote at Performance Now in 2024, users’ expectations are always changing. Millenials like myself are members of perhaps the last generation that can remember the sound of connecting to dial-up internet.
Annie Sullivan who works on the team at Chrome that developed the CWVs also stated in her Perf Now 2024 talk that the 75th percentile is just a starting point. Sometimes everyone gets the p99 experience — when that web page takes eons to load or respond to an interaction.
So I could see thresholds and targets shifting if Safari gets on board and also shares perf data like the Chrome User Experience Report (CrUX) — a publicly queriable performance dataset.
Safari behaves differently from the other major browsers
The Safari team has been pushing out a ton of features and fixes over the past few major versions that perf nerds have been hoping for: WebP and AVIF support, content-visibility, Web Components, font-size-adjust, loading=“lazy”, fetchpriority.
But the fact of the matter is: Safari is simply a different browser than Firefox and Chrome. And that’s how it should be. I for one prefer using Safari to other browsers on iPhone, but use different browsers for different tasks on desktop.
Release cycles and priorities differ amongst browser vendors, so one shiny new feature might not be baseline for months to years. To polyfill or not to polyfill? Improve perf for half of users but not for the other?
We developers, designers, product owners and managers need a common language like the CWV (and accessibility metrics and environmental metrics as well!) so that we can work together to provide the best, most inclusive experience to our users.
In the end, I like to think of it less than a browser war than a browser party. I know the performance community would be more than happy to share knowledge, ideas and feedback with Safari folk, e.g. on Perf Slack, at conferences such as Performance Now, posting on Web Performance Calendar and on podcasts, on standards boards and community working groups, etc.
So if Safari accepts the invitation to support CWV, I personally would toast to that.