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?
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 implicationsAlong 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. For web SaaS it’s a huge benefit. Because it allows you to download assets you know are needed prior to logging into your the SaaS app that would otherwise cause a huge initial load to be slow.
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.
3. If the concern is mobile bandwidth cost, simple solution is for Apple to only enable this feature for desktop Safari (not iOS).
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.
I have looked for something like this in macOS and can't find it. IMHO for a kernel that's also running on mobile devices not having a low data mode is inexplicable.
If the only advantage is for SaaS initial load time, then there are other solutions available for developers on a single domain (admittedly more complicated than "link rel=prefetch"). Meanwhile, the downsides and potential for abuse loom large.
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!
Because it allows you to download assets you know are needed prior to logging into your the SaaS app that would otherwise cause a huge initial load to be slow.
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.
I might be mistaken but I was under the impression that if you PRELOAD an asset, and that asset is not actually used on the page in which preloaded it - then that asset doesn't get cached for use on a future page. However, if you PREFETCH an asset and it's not used on that page - it does in fact get cached for future use.
I might be mistaken but I was under the impression that if you PRELOAD an asset, and that asset is not actually used on the page in which preloaded it - then that asset doesn't get cached for use on a future page.
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.
I keep hearing the argument that it’s a waste to prefetch assets that might not get used.
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?
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.
1. What? If you "need" them prior to logging in, they're going to be loaded regardless, and your app will be stuck until that happens regardless. How long do you think people are sitting at login screens?
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?
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.
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.”
So browsers should implement a new feature with known privacy implications…
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.
So this was solved by adding immeasurable complexity to a feature whose impact is dubious at best and potentially harmful (slow and/or metered internet) at worst.
Chrome aggressively pushes new "features" with pretty much zero-regard for user privacy.
Prefetch is a particularly good example in that it has no real benefit to the end user, while also providing yet another tool for tracking.
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've been using it for years as an alternative to FF, and the only things that sometimes feel sluggish are Google web apps. Honestly, I blame FUD for that one, not the browser itself. The battery life is pretty good too.
Extension-wise, I only have Hush and Adguard installed.
Now that I've tried it, is it just me or have they only implemented half of the feature? i.e. you can successfully visit such a link, but there's no way to create such a link yourself?
Really looking forward to playing around with this passkeys thing. If I understand it correctly, I can't implement it as the only authentication method for my website unless I'm okay with locking my users down to one single device?
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.
> 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?
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."
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.
Seconded. Their excuses for removing support are baffling (guess what? most current Safari adblockers still request access to "data from all websites", which is exactly what "Content Blockers" were supposed to prevent. So now, instead of open-source uBlock having access to all websites, people use proprietary extensions that have the same access. Ugh.)
It seems the criticism on Safari hasn't evolved alongside WebKit's efforts. It's true that WebKit is no longer lagging behind web standards (with the notable exceptions of PWAs and prefetch). Though I'll note that much of the criticism (see: IndexedDB) wasn't Apple lacking standards support, but having buggy implementations. I can't speak to Safari's dev tools because I just use Chrome's.
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.
They are late to the game as always. It seems like Chromium and Firefox are the first to implement, and Safari is consistently last. There are a few standards that Safari has been first to, but it is the exception.
Sometimes duplicate or wasteful features[0], but hey, Chrome's got those features!
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.
Every browser has instances of being the holdout on features, Safari does not stand out, especially amongst CSS features. Safari hasn't shipped touch-action, overflow-anchor, media queries range syntax. Chrome hasn't shipped the new viewport units, font-variant-alternates, or CSS subgrid. Chrome not supporting CSS subgrid is far more consequential than any CSS feature Safari is the holdout on.
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.
If a feature is not enabled in a browser by default, it doesn't count as "Yes, supported." Sites can't be designed expecting users will all go into their browser's experimental features list and turn things on.
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.
If a feature is not enabled in a browser by default, it doesn't count as "Yes, supported." Sites can't be designed expecting users will all go into their browser's experimental features list and turn things on.on
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.
By caniuse’s measure, being behind a flag is a ‘No’ for the reason I gave.
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.
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?
https://news.ycombinator.com/item?id=27365608