WebKit Features in Safari 16.1
webkit.org
webkit.org
Firefox v2 (2006) and Chrome v8 (2010) have had this feature for well over a decade.
A little more on this topic: https://nitter.net/Dieulot/status/1574763586055987200#m
EDIT: I realize there is an argument that this might be used for ad tracking but thought that was solved with some type of cache sandboxing that other browsers already have.
EDIT2: People keep saying it’s a privacy issue. Am I wrong in understanding that cache sandboxing mitigates this privacy concern?
iOS and macOS both support low-data mode, which Safari can know about, and disable prefetch in those cases.
It’s a little more nuanced than that.
1. prefetch has no role regarding initial page load, which is the thing most people care about most; not supporting it has no effect on that.
2. prefetch is a browser hint; during browser idle time, using some heuristic, it downloads resources in the background it thinks you might need or pages you might navigate to next. If it guesses correctly, the next navigation is fast, because the page and its resources, (assuming they have rel=prefetch assigned to them) is already in the cache. If the browser is wrong, there’s no benefit.
3. Users who don’t have unlimited cellular data and pay by the megabyte probably don’t want the browser downloading stuff in the background they didn’t ask for and may not need.
4. There are privacy implications. From Mozilla’s Link prefetching FAQ [1]:
Privacy implications Along with the referral and URL-following implications already mentioned above, prefetching will generally cause the cookies of the prefetched site to be accessed. (For example, if you google amazon, the Google results page will prefetch www.amazon.com, causing amazon cookies to be sent back and forth. You can block 3rd party cookies in Firefox, see Disabling third party cookies.)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
2. What you described sounds like a net positive since you didn’t state any negatives.
3. If the concern is mobile bandwidth cost, simple solution is for Apple to only enable this feature for desktop Safari (not iOS).
4. There is a technical solution with cookie sandboxing.
2. No, it's a statement that a correct implementation of preloading is free ignore any of your requests. So it's a net neutral.
3. No one said anything about mobile, so I don't know where you got this from?
4. So browsers should implement a new feature with known privacy implications, and then concurrent with that implement yet another mechanism to prevent the brand new privacy violation from from doing just that? Presumably so that people can then go around complaining about how unnecessarily complex browsers are?
I have a simply question: based on [1] why are you not just using XHR or non-blocking script tags?
That’s not the way the spec is written for rel=preload.
From § 4.6.7.19 Link type “preload” [1]:
The preload keyword indicates that the user agent will preemptively fetch and cache the specified resource according to the potential destination given by the as attribute (and the priority associated with the corresponding destination), as it is highly likely that the user will require this resource for the current navigation. [PRELOAD]
This sentence is quite clear:
A user agent must not delay the load event for this link type.
The point of preload is to tell the browser “hey—I know you’re busy but this resource is really important for the current page and I need you to prioritize downloading it. I know you’re not aware of this resource because you haven’t parsed that section of the HTML or CSS yet, but trust me, I need you to start downloading it right now.”
The browser is not free to “ignore the request”, which would defeat the purpose of having a directive that tells the browser you want a particular resource to jump to the head of the download queue.
There are other directives that are hints or suggestions, kind of like saying to the browser “if you’re not too busy and you have the bandwidth available, could you download this resource? I don’t need it for the current page but there’s a good chance I’ll need it for the next page the user is likely to access next. It’s not a big deal if you can’t get to it right away.”
[1]: https://html.spec.whatwg.org/multipage/links.html#link-type-...
Gee, I wonder what company makes the vast majority of their revenue by selling ads on their dominant search engine by enabling users to be tracked all over the web? Oh, and this same browser is the only major browser that doesn’t block 3rd party cookies by default?
Safari, Firefox, Brave, Edge provide privacy preserving features to keep their users from being tracked.
It’s in Google’s financial interest to go easy on blocking 3rd party cookies and tacking.
Most people encounter SaaS initial load time much more rarely than they do web advertising or unscrupulous web developers, and SaaS providers have other ways of more accurately measuring traffic than means which are distorted by prefetching.
I, for one, have disabled what little pre-fetching Safari does offer, the "Preload Top Hit in Background" option under Search preferences. No thank you!
"Cellular/limited data" and "on a mobile device (smartphone or similar)" are equivalent.
That’s what rel=preload does, not rel=prefetch. As I mentioned, prefetch runs during idle time and the browser certainly isn’t idle when doing an initial page load.
Of course Safari supports rel=preload.
Is my understanding incorrect?
The point of using rel=preload is because you want to start downloading a resource before it’s discovered in your HTML or CSS for the current navigation. If the resource doesn’t get used on the current navigation, it stays in the cache, because you said you needed the resource.
However, preloading something then not using it is a waste of bandwidth and possibly screws up the priority of how resources load. If you preload something and you don’t use it, that bandwidth could have been used to download something you do use.
If you need something for the next navigation—say your homepage is splash page and you want a nearly instantaneous transition to the next page—that’s when you would use prefetch. When the user navigates to the next page, all of your important resources are in the cache and can be used immediately.
If your resources are on servers that aren’t your origin (like a CDN) but you don’t need them yet, you can use rel=preconnect, which does the DNS lookup and the TLS handshake in the background, so when it’s time to download from the CDN, you’re not delayed by the DNS lookup and the TLS handshake, because it’s already done.
If you need resources from several different non-origin servers, the amount of time for DNS lookups and TLS handshakes starts to add up.
Yet, is it ok that so many web developers use bloated JS libraries that causes websites to be multiple MBs in size when it could easily only be 10s of KB?
How is that not a bigger waste?
You’ll get no argument from me regarding bloated JS libraries. But the reason why preload was created to make page downloads faster, not reduce asset sizes.
I keep hearing the argument that it’s a waste to prefetch assets that might not get used.
Preloading assets you don’t use can be a waste of bandwidth because that bandwidth could have been used to download something you’re going to actually use. Also, preload bumps up the priority of that resource, perhaps jumping ahead of an asset you really need.
For users with the latest devices on broadband connections, it may not make much of a difference. But when you’re cell connection is two bars and you’re on 3G instead of 5G, it matters.
Short answer: no. A laptop could be using a metered mobile hotspot while an iPhone could be on a fast Wi-Fi network.
There’s away to indicate a user wants to save data [1]. This would tell the service to not do things like download resources in the background I may not need or use, which is what rel=prefetch does.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sa...
Outside of this there are a bunch of features that are implemented in webkit, that are not enabled in the system frameworks due to them having significant cost to end users.
I'm not sure why I don't find myself using safari more yet, but maybe soon it'll get there.
Extension-wise, I only have Hush and Adguard installed.
Edit. Johnathan Nightingale was General Manager and Vice President of the Firefox group at Mozilla. He knows what he's talking about.
https://webkit.org/blog/13399/webkit-features-in-safari-16-1...
Edit: to clarify, if my user set up passkey on their iPhone and that's the only method of authentication for my website, they just wouldn't be able to sign in if they lost that iPhone? The key can't be recovered, transferred or backed up? I'm okay with that (I own several yubikeys myself), just want to make sure I understand it correctly.
Because it’s based on Webauthn, I believe a website can fall back to using a compatible security key (like a YubiKey) as authentication.
That used to be the case. Since iOS 16 they are also synced via the iCloud Keychain: "Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID."
https://support.apple.com/guide/iphone/sign-in-with-passkeys...
Short answer: yes. In Safari 16.1, select Preferences > Websites and uncheck “Allow websites to ask for permission to send notifications”.
Details about WebKit’s Web Push implementation and how privacy is handled [1]:
Also, in Safari you will not get spammed by requests for permission to send notifications. A website or web app can only ask for permission _after_ you've indicated interest with a gesture — like clicking on a "subscribe" bell icon, or a button that says "notify me". They are not allowed to ask you until you've taken the first step.
But if critics keep focusing on webcompat, they might comfort the WebKit team into thinking that all the criticism is unwarranted, and that Safari has caugh up. That's not the case when it comes to the user experience, where Safari still lags far behind.
Just weeks ago, Safari lost me a few tabs, twice. The tabs kept the favicon, but became "Untitled", and when you clicked on them, they were just blank, and the "back" button was disabled. Does this version fix it? No clue, because they never acknowledged that bug publicly. Never had a bug like that on Chrome, in the decade I've used it.
Safari still doesn't allow users to select multiple tabs to move them to other windows or move them to tab groups. Firefox and Chrome both can.
The "back" button is still finicky. The button bizzarely feels more reliable than the trackpad gesture. The full-page animation makes it feel much slower than Chrome, which doesn't have a page-back animation except a small left arrow no the side. There's a huge bug, that's survived for many years and which I encounter very frequently: when you Google something, click on a result, then go back, you end up at the Start Page rather than the Google search, which isn't even in the History. How?
Extension support on iOS is far better than competitors, but on the Mac, Apple's clearly saying "fuck you" to extension developers. Forcing devs to pay, making basic APIs unavailable without good reason (webRequest blocking; they really should just implement whatever gorhill tells them to; I thought they disliked ads and tracking?), and cluttering users' Applications folders with browser extensions unlike every other browser. Why can't I use the Bypass Paywalls Clean extension with Safari? uBlock Origin? SingleFile? There's a long-tail of extensions that Safari will never support, due to the Safari team's practices.
And why lack support for profiles? I don't want to switch user accounts; I just want to be able to segregate work and personal, so my URL autocomplete doesn't show personal stuff at work. That's a basic requirement in the era of screen sharing and streaming.
Tab groups are an encouraging feature, that shows Apple cares about power users, but Safari still feels too "restricted" and rigid. There's a strong feeling that "Apple knows best" and feel they can dictate the user experience, which just doesn't work for something as personal as a browser. No, it wouldn't be "un-Apple-like" to roll out Profiles, or proper extension support that don't clutter the apps folder. Worried about malware extensions? Then improve your analytics, and rely on Apple's ability to remote-uninstall bad extensions, like Firefox and Chrome have done. They're just hurting power users, with little benefit for average users who mostly don't install extensions anyway.
Chrome ships hundreds of new web APIs a year. Most of them are Chrome-only non-standards. Firefox and Safari are more closely aligned: https://web-confluence.appspot.com/#!/confluence
Edit: Safari also has no support for CSS counter styles or CSS paged media while Chrome and Firefox have at least partial support. Again, those don't seem particularly consequential features for moving web design forward.
https://caniuse.com/?compare=chrome+106,safari+16.0,firefox+...
When I read this, I turned on css counter styles on my iPhone:
Settings > Safari > Advanced > Experimental features.
There are a lot of in-development web features that can be enabled.
Some CSS features can be used even without widespread browser support because the content's meaning isn't changed in browsers that don't support the feature; border-radius is a classic example. For something like CSS counter styles, if an ordered list is equally well-understood with the default numbers or the custom styles, they can be fine but it's easy to think of examples where meaning would be lost without the counter styles.
I didn't claim this was a supported feature, just that it wasn't accurate to suggest that WebKit has no support for some of these features that seem to be missing. They are being worked on and will be turned on by default pretty soon.
Being available as an experimental feature does not mean its release is imminent, there are ones that have been there for years. Thankfully, it’s not like they’re in a queue, some are released after only a few months.
Or alternatively actually answer the question like an adult rather than parroting the standard Apple hates the web nonsense.
In case nobody noticed, the WebKit team kicked ass by shipping a ton of new features this year:
* dialog element
* lazy loading
* inert
* :has() pseudo-class
* new viewport units
* Cascade Layers
* focus visible
* accent color
* appearance
* font palettes for color fonts
* BroadcastChannel
* Web Locks API
* File System Access API
* enhancements to WebAssembly
* support for Display-P3 in canvas
* additions to COOP and COEP
* container queries
* subgrid
* web push
* shared workers
* CSS Offset Path
* AVIF
* Passkeys
Meanwhile, on interoperability[1], Firefox and Safari are currently at 84, while Chrome is at... 75. Once they update with this new release, Safari should climb to 89[2].
Being first to things isn't always the great thing you're suggesting, if those things aren't actually being asked for--or wanted.
0. https://lists.webkit.org/pipermail/webkit-dev/2021-March/031...
Also, it's terrifying because it's just one of hundreds of standards that WebKit (and Firefox) might not have the time and resources to fight.