6 ms·

Still no prefetch to help websites load faster :( It’s a little more nuanced than that. 1. prefetch has no role regarding initial page load, which is the thin

Still no prefetch to help websites load faster :( 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_prefetching_FAQ#privacy_implications https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

alberth 4y ago
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.
- olliej 4y ago
  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?
  - alwillis 4y ago
    Read the specs—preload ≠ prefetch.
    - olliej 4y ago
      Simply saying "hey I don't think you know jack shit" without actually answering any of my points is glib and unhelpful.
  - alwillis 4y ago
    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.” [1]: https://html.spec.whatwg.org/multipage/links.html#link-type-preload https://html.spec.whatwg.org/multipage/links.html#link-type-...
  - alwillis 4y ago
    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.
- pwinnski 4y ago
  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!
- danaris 4y ago
  Falsehoods Programmers Believe About Network Connections, #4827: "Cellular/limited data" and "on a mobile device (smartphone or similar)" are equivalent.
- alwillis 4y ago
  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. Of course Safari supports rel=preload.
  - alberth 4y ago
    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. Is my understanding incorrect? https://html.spec.whatwg.org/multipage/links.html#linkTypes https://html.spec.whatwg.org/multipage/links.html#linkTypes
    - alwillis 4y ago
      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.
- alwillis 4y ago
  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. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sa...
  - fomine3 4y ago
    If your Mac is connected to metered mobile network, for example, you don't want to download software updates automatically. To support such situation, Windows supports "metered connection" settings to distinguish connection. Some apps regard the settings so it save data usage until it connect to unlimited connection. https://support.microsoft.com/en-us/windows/metered-connections-in-windows-7b33928f-a144-b265-97b6-f2e95a87c408 https://support.microsoft.com/en-us/windows/metered-connecti... https://www.windowslatest.com/2020/11/17/chrome-will-finally-support-windows-10-metered-network-feature/ https://www.windowslatest.com/2020/11/17/chrome-will-finally...
    - ultrarunner 4y ago
      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.

alberth 4y ago

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.

olliej 4y ago
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?
- alwillis 4y ago
  Read the specs—preload ≠ prefetch.
  - olliej 4y ago
    Simply saying "hey I don't think you know jack shit" without actually answering any of my points is glib and unhelpful.
- alwillis 4y ago
  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.” [1]: https://html.spec.whatwg.org/multipage/links.html#link-type-preload https://html.spec.whatwg.org/multipage/links.html#link-type-...
- alwillis 4y ago
  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.
pwinnski 4y ago
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!
danaris 4y ago
Falsehoods Programmers Believe About Network Connections, #4827: "Cellular/limited data" and "on a mobile device (smartphone or similar)" are equivalent.
alwillis 4y ago
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. Of course Safari supports rel=preload.
- alberth 4y ago
  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. Is my understanding incorrect? https://html.spec.whatwg.org/multipage/links.html#linkTypes https://html.spec.whatwg.org/multipage/links.html#linkTypes
  - alwillis 4y ago
    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.
alwillis 4y ago
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. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sa...
- fomine3 4y ago
  If your Mac is connected to metered mobile network, for example, you don't want to download software updates automatically. To support such situation, Windows supports "metered connection" settings to distinguish connection. Some apps regard the settings so it save data usage until it connect to unlimited connection. https://support.microsoft.com/en-us/windows/metered-connections-in-windows-7b33928f-a144-b265-97b6-f2e95a87c408 https://support.microsoft.com/en-us/windows/metered-connecti... https://www.windowslatest.com/2020/11/17/chrome-will-finally-support-windows-10-metered-network-feature/ https://www.windowslatest.com/2020/11/17/chrome-will-finally...
  - ultrarunner 4y ago
    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.