4 ms·

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.

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.
  - alberth 4y ago
    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? How is that not a bigger waste?
    - alwillis 4y ago
      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.

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.
- alberth 4y ago
  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? How is that not a bigger waste?
  - alwillis 4y ago
    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.