That is, a preload, followed immediately by using it (rather than using it much later in the document, as was the original intent of preload links).
(On this submission, servers.json receives this treatment. While talking of servers.json, two things are odd about it: although served as JSON, it’s actually JavaScript, and a random cache busting parameter is added to its query string, rather than the server just instructing the client not to cache it.)
I cannot imagine any way in which this makes sense: the preload line should be 100% superfluous (and thus mildly counterproductive). Is there some utterly bizarre reason why this does actually help things, or is it just simple cargo culting of a corrupted idea as I presume?
I think it's more of a resource prioritisation thing.
I THINK If the resource is async, it will still scan the document to find all resources before the downloads begin. Adding preload basically just tells the browser that the resource is important and should begin the download immediately.
Hmm, interesting. That makes sense. Thanks for the info.
Every single time I’ve seen it done, it’s been used for all scripts. I’ll have to check at some point whether what you think is correct or not. I can easily imagine it going either way.
(Edit: actually, on reflection, sometimes there may be analytics-type scripts that don’t get this treatment, so yeah, if that’s the case it would make sense.)
(On this submission, servers.json receives this treatment. While talking of servers.json, two things are odd about it: although served as JSON, it’s actually JavaScript, and a random cache busting parameter is added to its query string, rather than the server just instructing the client not to cache it.)
I cannot imagine any way in which this makes sense: the preload line should be 100% superfluous (and thus mildly counterproductive). Is there some utterly bizarre reason why this does actually help things, or is it just simple cargo culting of a corrupted idea as I presume?