4 ms·

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 yo

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

by olliej 4y ago

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.