prefetch/preload names too similar

[ewinslow]

This is a pretty minor point, but my first reaction to seeing this was, "what's the difference between prefetch and preload?"

So I guess the main difference as noted in #1 is priority. preload is for resources that will probably be required on the current page. prefetch is for resources that may be required on the next page. Did I get that right? Or is it the other way around?

I can think of a few ways to remedy this confusion:

• Come up with a new naming convention to make the distinction clearer
• Implement #2
• Document the distinction explicitly for those like me who might get confused.

Thanks for working on this!

[igrigorik]

• Preload is used to indicate resources that should be fetched as early as possible.
• Prefetch is used to indicate resources that may be required by the next navigation.

Preload is a way to communicate, in a declarative fashion, with the preload scanner. While the preload scanner is not guaranteed to execute the resource, the hint should be used for resources that are critical to the current page - i.e. you definitely need them. If you're unsure if the resource will be needed, you shouldn't preload it to minimize resource contention during the initial load (aka, don't compete with JS, CSS and other critical assets).

Prefetch, on the other hand, is best understood as "I think I will need this in the future, please fetch it when/if you can, but please make sure that while you do so, you don't slow down the current page".

[bmaurer]

What would an ajax application use for a JS file that was needed to handle a user interaction. Eg, imagine that in gmail the "new email" button needed JS that isn't required with the main page. Because gmail is an ajax application, this isn't for "the next page load". But it also might want to communicate this resource isn't as important as things that it wants to preload.

Would it be possible to combine the preload and prefetch into one thing that just had different priorities? Eg, a resource for the next interaction would be a low priority prefetch.

[igrigorik]

@bmaurer preconnect and preload are used to help get initial pixels on the screen faster - i.e. get requests for initial critical resources out as soon as possible. prefetch and prerender are for going one step further and hinting those same critical resources (or entire page) before you initiate the navigation.

The great big area in between where the page is loaded and user is interacting with it, is and should be handled by existing primitives like XHR and/or injecting appropriate elements via JavaScript.

Should we have some extra flags on XHR and other request types to fiddle with the priority of each? Probably, but that's also a separate discussion from Resource Hints. If such mechanism existed, RH would simply be one consumer of it.

[bmaurer]

(sorry, github is unable to deal with html in comments. ugh)

My apologies if I'm hijacking the discussion of Resource Hints to talk about something that should be a separate discussion. Let me know if what I'm talking about here is out of the scope of what you're thinking about for this spec.

XHR / JS inserted < script async> tags seem like the poor choice for the example of the "compose email" button -- the document might do it too early and compete with bandwidth that makes the page interactive, or could be too conservative and not use the available bandwidth. Some of the other discussions (eg, making preload a MUST or having onload events) suggest that there's interest in using this in "The great big area in between where the page is loaded and user is interacting with it".

It seems like part of the confusion in this bug is that "preload" vs "prefetch" is a kind of prioritization flag, but is not explicitly labeled as one. If the Link header were < link rel="prefetch" priority="{immediate,background}"> it seems like it might solve the confusion and avoid the need for a separate, possibly conflicting priority attribute in the future.

As some context for how I'm thinking about this: at Facebook we have our own javascript-based resource scheduler. We hide JS/CSS URLs from the preload scanner. The resource scheduler is able to do things like "only download the JS for messaging after the newsfeed JS is downloaded". The question I've been asking myself is "could we reasonably expose all of our JS/CSS declaratively to the browser".

[igrigorik]

Preload/prefetch are not prioritization flags. Preload is about improving timing of when the UA recognizes and dispatches the request. Prefetch is about allowing the request to persist across navigations. Relative to each other, yes, they have different priority levels, but that's about it

Prioritization is a much deeper discussion that I don't want to get into now: prioritization classes, class relationships between different resource types, protocol capabilities (HTTP/2) like reprioritization and dependency chains, etc. This is a separate spec.

P.S. The actual question you want to ask is.. not whether you can expose the dependency chain to the browser, but to the server. And the answer, at least in theory, is yes: HTTP/2 priorities, on paper, allow us to create dependency trees.

[bmaurer]

Maybe prioritization was the wrong word for me to use: preload vs prefetch seem like a modifier on the same behavior (asking the browser to download some resource). Do you think that a scheme like: < link rel="prefetch" reason="subresource"> and < link rel="prefetch" reason="navigation"> might be easier for developers to understand or to extend with a deeper set of priorities? I could also imagine this distinction being useful for preconnect (preconnect to a CDN vs preconnect to a link shared in my feed)

I think your point about communicating to the server is very insightful. What if the developer could send a free-form prioritization hint to the server (ideally one that allowed that hint to change, so that the server could reprioritize). This would be simple to spec out and developers could experiment with different prioritization strategies without needing new browser features.

[igrigorik]

I think it would make more sense to merge prefetch & prerender: see #2.

Re, priority: not sure it would be simple to spec out ;-) ... We need proper protocol capabilities in place, plus lots of thought on a coherent API. In any case though, much of the necessary low level plumbing is being discussed in HTTP/2: http://http2.github.io/http2-spec/#StreamPriority. Dependencies in particular are new, so we need some experience with them first before we rush to expose them.

[igrigorik]

Closing this, let's continue the discussion in #2.

(feel free to reopen if feel otherwise :))