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

Preloading images corresponding to picture element #131

Closed
domfarolino opened this Issue Oct 15, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@domfarolino
Copy link
Contributor

domfarolino commented Oct 15, 2018

This issue is a follow-up to the HTML PR I made to support imagesrcset and imagesizes attributes on the <link> element. Some complications arose with the <picture> element use-case. In summary, I believe the first image source in a <picture> element whose media matches the environment is chosen to be loaded, and the rest are not loaded (until necessary). This contrasts with naturally independent <link rel=preload>s, in which all requests are mandatory.

If the author of a site is trying to preload images that a <picture> element may choose between, there will be n - 1 wasted preloads for a given viewport. It seems that there are two solutions to this:

  • The author makes the <link rel=preload>s have mutually exclusive media queries, so that only one will be preloaded, the one that would be chosen in the <picture>. As noted, this might not always be feasible or easy for authors, and puts the burden on them.
  • The platform provides some sort of way to explicitly link <link rel=preload>s together, so the UA knows that they ~correspond to a <picture>, and the same selection algorithm can be applied to choose the image to load. One proposal was to create a new rel value to indicate this.

Thoughts? The latter seems to make sense, but I just want to make sure it is worth the complexity.

/cc @irori @zcorpan @developit

@yoavweiss yoavweiss added the discuss label Oct 16, 2018

@yoavweiss yoavweiss added this to the Level 2 milestone Oct 21, 2018

@toddreifsteck

This comment has been minimized.

Copy link
Member

toddreifsteck commented Oct 26, 2018

Discussed at TPAC 2018. Here is a summary based upon my interpretation of what was discussed:

  • This adds a lot of complexity to preload's processing model
  • There is not a clear, simple way to specify and implement
  • This can be achieved almost as efficiently using a hidden picture element at the top of the body
  • Because of this, we agreed to punt on investing further efforts until a real web site reports a need that cannot be worked around.
  • Even when that need is reported, we believe it is likely to attempt to solve it by simpler modifications to preload than adding full picture capabilities.
@domfarolino

This comment has been minimized.

Copy link
Contributor

domfarolino commented Oct 26, 2018

Thanks for the summary, so to be clear, are we agreeing to abandon the HTML Standard PR supporting this?

@toddreifsteck

This comment has been minimized.

Copy link
Member

toddreifsteck commented Oct 26, 2018

@domfarolino Let me put a quick summary in #120

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Oct 29, 2018

Closing at this was the consensus in the group during the F2F. If and when we get reports that this is a missing capability which results in worse performance for production websites, we can reconsider.

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