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

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