4 ms·

Still no PREFETCH to help websites load faster :( Firefox v2 (2006) and Chrome v8 (2010) have had this feature for well over a decade. A little more on this t

Still no PREFETCH to help websites load faster :( 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 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 https://news.ycombinator.com/item?id=27365608

dmitriid 4y ago
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.
- concinds 4y ago
  > potentially harmful (slow and/or metered internet) at worst iOS and macOS both support low-data mode, which Safari can know about, and disable prefetch in those cases.
alwillis 4y ago
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-...
caycep 4y ago
This was pre-webkit fork by Chrome, right? is this something outside of webkit then?
- olliej 4y ago
  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.

dmitriid 4y ago

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.

concinds 4y ago
> potentially harmful (slow and/or metered internet) at worst iOS and macOS both support low-data mode, which Safari can know about, and disable prefetch in those cases.

alwillis 4y ago

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-...

caycep 4y ago

This was pre-webkit fork by Chrome, right? is this something outside of webkit then?

olliej 4y ago
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.