New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for review: Preload #202

Closed
yoavweiss opened this Issue Sep 26, 2017 · 8 comments

Comments

Projects
None yet
8 participants
@yoavweiss

yoavweiss commented Sep 26, 2017

Hello TAG!

I'm requesting a TAG review of:

Further details:

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]

@yoavweiss yoavweiss referenced this issue Sep 26, 2017

Closed

Transition Level 1 to CR #76

5 of 7 tasks complete
@cynthia

This comment has been minimized.

Member

cynthia commented Sep 27, 2017

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

@triblondon

This comment has been minimized.

triblondon commented Sep 27, 2017

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

This comment has been minimized.

triblondon commented Sep 27, 2017

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

@triblondon triblondon closed this Sep 27, 2017

@igrigorik

This comment has been minimized.

igrigorik commented Sep 27, 2017

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:

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

@triblondon

This comment has been minimized.

triblondon commented Sep 28, 2017

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

This comment has been minimized.

yoavweiss commented Sep 28, 2017

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

This comment has been minimized.

Member

plinss commented Sep 28, 2017

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

This comment has been minimized.

Krinkle commented Sep 28, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment