Àlex Corretgé

I keep reading that Safari is faster than Chrome. I switched a while ago, though honestly more for the privacy side than for speed, and that's still why I stay. But some of the heavy sites I use all day never felt faster to me. Gmail especially. It's always been a bit slow on Safari compared to Chrome, and I just assumed that was part of the deal and got on with it. Today I read Apple's switch-to-Safari page and figured I should actually check instead of just having an opinion about it. Spent the afternoon measuring, with a lot of help from Claude. Most of what I expected to find was wrong, which is fine, that happens. But I did find one thing, and I'd rather ask @gmail about it than guess. Gmail has its own check for service worker support. Basically: does navigator.serviceWorker exist here. In Safari it does, and the check passes. But the code that actually decides takes that result and also requires the browser to be Chrome 52 or newer, or Firefox 44 or newer. Safari isn't on the list. It's not that the code doesn't know about Safari. The same file has a Safari constant and checks its version in other places. It just doesn't use it for this. Here's what that costs. Same machine, same mailbox, same minute. The only thing I changed was the user agent string: responseStart: about 450ms to 3ms domContentLoaded: about 1100ms to about 75ms first contentful paint: about 870ms to about 360ms With the check passing, Gmail registers the worker, caches the document and serves the page out of Cache Storage. It works. I used it for a while and nothing broke. And once it's registered it stays registered, even after you put the user agent back to Safari, so you keep the speed. Web Locks looks the same. The code checks whether the browser supports it, finds that it does, and then still asks for Chrome 69 or newer. Safari has supported Web Locks since 15.4. To be clear about what this isn't: it doesn't explain why Gmail feels slow to use in Safari. The dropped frames I measured are around 8x Chrome, and turning the service worker on didn't change that at all. That part is still a mystery to me, and some of it is probably on WebKit. These browser lists also usually start as a workaround for a real bug, and then nobody goes back to them. There's even a server-side flag in the same code that would switch it to a plain capability check. So: what's the reasoning for leaving Safari out? Something that breaks that I haven't run into, support cost, or just a list from 2018 that nobody has had a reason to revisit? Any of those is a fine answer, I'd just like to know which one. Tagging @googlechrome and @webkit as well, since it touches all three. Happy to share the measurements, the scripts, and a small file you can run in both browsers in about ten seconds to see it yourself. If you work on any of this and want to compare notes, or tell me where my method is off, please do. I'd rather find out I'm wrong than keep repeating this.