Request for review: Preload

[yoavweiss]

Hello TAG!

I'm requesting a TAG review of:

• Name: Preload
• Specification URL: https://w3c.github.io/preload/
• Explainer, Requirements Doc, or Example code: https://w3c.github.io/preload/#introduction
• Tests: https://w3c-test.org/preload/
• Primary contacts: @igrigorik @yoavweiss

Further details:

• Relevant time constraints or deadlines: Not really
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that the feature already has shipping implementations in 2.5 browsers (Chrome, Firefox 57 and Safari Tech Preview). It is also used by 0.9% of page views.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[cynthia]

I was just thinking about to bring up the review with you folks. Thanks for submitting.

[triblondon]

Hi @yoavweiss,

Thanks for raising this review with us, and congrats on the adoption. We have three points of feedback:

• There's a nopush, but no corresponding push-only (which would push but strip the header). We note that Jake recommends doing this in his H2 research
• If a client requests an HTML page, and the page has a link preload header for a logo image, but the server has two variants of that logo, PNG and WEBP, which do we push, given that the Accept header on the HTML request is not providing information about the client's preferred image formats. Do we need some kind of Accept extension?
• We're nervous of developer confusion between prefetch and preload. What efforts are being made to explain the difference between the two, and is it time to deprecate prefetch officially?

[triblondon]

Review raised, completed and closed within 24 hours. This is a TAG record.

[igrigorik]

Review raised, completed and closed within 24 hours. This is a TAG record.

👏 👍

If a client requests an HTML page, and the page has a link preload header for a logo image, but the server has two variants of that logo, PNG and WEBP, which do we push, given that the Accept header on the HTML request is not providing information about the client's preferred image formats.

That's not true, and we learned this the hard way a few times over now. Browsers that support WebP should (and do) advertise webp on all requests; same best practice applies to all other formats.

We're nervous of developer confusion between prefetch and preload. What efforts are being made to explain the difference between the two, and is it time to deprecate prefetch officially?

No it's not, but we can probably make prefetch better and smarter. In terms of differences, preload and prefetch serve different purposes. Addy and Yoav have good explainers here:

• https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf#89a4
• https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#didnt-we-already-have-that

Open to suggestions on how to explain prefetch better, let's route that feedback into Resource Hints spec.

[triblondon]

... the Accept header on the HTML request is not providing information about the client's preferred image formats.
That's not true, and we learned this the hard way a few times over now.

My testing indicates that browsers do send different Accept headers based on the instigator of the request (and in the case of preload, the value of as). It seems therefore conceivable to me that a request for one type of resource which prompts a push of a different type of resource, would leave the server in an uncertain position if there were multiple variants of the pushable resource available. Are you saying that this is never a problem, or it's not a problem as long as pushes are only done in response to navigation requests, or that I'm wrong about the variation in the value of Accept?

[yoavweiss]

I think you both are talking about different things. What @igrigorik is saying is that when preload is used as a browser signal, the browser will send the appropriate Accept headers based on the as value. (so as=image will send out e.g Accept: image/webp,image/*,*/*;q=0.8 in Chromium)

IIUC, @triblondon is talking about using preload as a push signal, and lack of content-negotiation in that case. That's not a problem with preload, as no markup or server side mechanism could have helped here. HTTP/2 push cannot perform content negotiation, as by definition the client does not take part in the generation of the request. That's one of the advantages of preload over push.
Maybe we can add that as a note saying that when a server plans to use content negotiation to serve a resource, it should not attempt to push it.

[plinss]

My thinking is that maybe we need a mechanism in http/2 where the client can pre-send accept headers for other resource types (possibly prompted by the server before it does the push) so the server can make the push match what the client would have negotiated via a normal fetch. This is obviously an issue for http/2 rather than preload and I'll follow up there.

[Krinkle]

For the record, the Accept header in Chrome for navigation requests (which will be available to a push-enabled server) does contain the supported image formats as well:

GET /w3ctag/design-reviews/issues/202 HTTP/1.1
Host: github.com
User-Agent: .. Chrome/61.0.3163.100
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

I don't know if that is standardised and intended to be used for this purpose, but it is one possible way to inform servers of supported formats of sub resources.

For the case of other non-image files (such as fonts) this wouldn't suffice right now. For fonts, preload has a type attribute, where generally only the "best" format is requested, but while that solves the issue for preload, it does not solve it for push. What is the intended strategy there?