Intent to Implement: image async attribute

2,613 views
Skip to first unread message

Vladimir Levin

unread,
Oct 6, 2017, 2:41:39 PM10/6/17
to blink-dev, Chris Harrelson

Contact emails

vmp...@chromium.org, chri...@chromium.org


Explainer

https://docs.google.com/document/d/1VvrEGAjcnto5egR_rnX7PR5ymqWayMNRPYSbCf1bC4I


Summary

We propose to introduce an async attribute on HTMLImageElement and SVGImageElement which would act as a hint to Chrome. This attribute would have two states:

  • “on”: This indicates that the developer prefers responsiveness and performance over atomic presentation of content.

  • “off”: This indicates that the developer prefers atomic presentation of content over responsiveness.


Motivation

Currently different browsers deal with deferring images differently. Chrome and Safari by default present content atomically (images and text appear together). Visually this looks correct but can have janky behavior since decoding images delays presentation of non-image content. Edge and Firefox by default have a heuristic that may allow image decodes to be deferred and present content without images. This avoids jank and presents non-image content faster, but can occasionally cause visual flashes or popping in of images that the developer did not intend.


This attribute would give developers a tool specify their intent and preference directly.


Risks

Since this attribute acts as a hint, there is little risk in interoperability. Specifically, if other browsers do not implement it, they would not be necessarily violating the spec. Additionally, since this is an attribute browsers may decide not to parse this value at all with no detriment to either the developer or the user.


If we need to remove this feature, it would also be straight forward in that content may still use the attribute but Chrome can silently ignore it.


Edge: No signals.

Firefox: No signals.

Safari: In development (a version of the attribute is in the Safari developer preview release 40)

Web developers: Positive (AMP team indicated desire to start using the attribute)


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4897260684967936


Requesting approval to ship?

No.


Ian Kilpatrick

unread,
Oct 6, 2017, 3:24:53 PM10/6/17
to Vladimir Levin, blink-dev, Chris Harrelson
(note: the new intent to implement process now requires a TAG review to be kicked off or an explanation for why it is being skipped)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Mofd%2Bo%2B0PU6CWoGM2tMqoREGWxzpoRvXowosWHezYTPA%40mail.gmail.com.

Addy Osmani

unread,
Oct 6, 2017, 3:29:30 PM10/6/17
to blink-dev, chri...@chromium.org, vmp...@chromium.org
I'm excited to see efforts to give developers more control over scheduling asynchronous image decodes off the critical path. 

My initial gut reactions to the current sketch after reading the explainer were:
  • The "async" attribute naming doesn't immediately indicate we're referring to image decoding here. This may be a non-issue as "async" on <script> doesn't name-call script execution but developers otherwise know what it accomplishes.
  • I initially questioned why we needed "async=on/off" vs. just "async". I guess given the variance in cross-browser behavior, being able to deterministically hint "please try not to defer decoding, these are critical images" has value.
  • I'm curious if we should think about <img async> as we design Priority Hints. We've mostly been focusing on the network priority parts there, but the topic of whether it also controls "processing" work like script execution and image decoding did come up at BlinkOn. I think we're going to punt on thinking about "processing time"/ decoding etc. for now.

Mathias Bynens

unread,
Oct 6, 2017, 3:32:19 PM10/6/17
to Ian Kilpatrick, Vladimir Levin, blink-dev, Chris Harrelson
My first reaction was “why not a boolean attribute” but the explainer doc made it clear: the absense of the attribute indicates that the browser is free to do whatever it deems fit.

<!-- The decode for this image may be deferred: -->
<img async=on src=foo>

<!-- if possible, the decode for this image should not be deferred: -->
<img async=off src=foo>

<!-- The browser is free to do what it feels is best for the user: -->
<img src=foo>

I would prefer a more descriptive attribute + list of values, e.g. decode="async" + decode="defer".

Mathias Bynens

unread,
Oct 6, 2017, 3:36:33 PM10/6/17
to Ian Kilpatrick, Vladimir Levin, blink-dev, Chris Harrelson

nekr....@gmail.com

unread,
Oct 6, 2017, 4:33:23 PM10/6/17
to blink-dev, ikilp...@chromium.org, vmp...@chromium.org, chri...@chromium.org
I also like `decode="async"` instead. It is not clear at first why not boolean and I believe many people will be confused by that at first. Also, since <script> and <img> will have different meaning of async (in terms of values) it may cause people mistakenly just add `async` to image thinking that's `on`.

Also, what this code `<img async src=foo>` will mean? `on` or default?

пятница, 6 октября 2017 г., 22:32:19 UTC+3 пользователь Mathias Bynens написал:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Vladimir Levin

unread,
Oct 6, 2017, 4:54:51 PM10/6/17
to Domenic Denicola, nekr....@gmail.com, blink-dev, ikilp...@chromium.org, chri...@chromium.org
Thank you for the replies.

The point about the name being unclear is well taken and this is something we'll definitely be considering as we move forward. I do agree with domenic@ that this is something that is definitely subject to change but in order to test things even locally, we just need a name for now. The reason we picked async is because of Safari's shipping async attribute as a part of the developer preview. Safari's attribute has very similar semantics to this proposal, the exception being that it is a boolean flag: it is either present or not. 

re tag review: I apologize I didn't realize that it was mandatory in the new guide; I think at this point, considering the possible name change, and possibility of change the on/off to a boolean value (see https://github.com/whatwg/html/issues/1920), the tag review might be premature.

I will update this with more details on name and tri-state vs two-state aspects when we have a larger consensus.

Thanks,
Vlad

On Fri, Oct 6, 2017 at 1:38 PM, Domenic Denicola <d...@domenic.me> wrote:

I think bikeshedding on the name is not productive on this thread:

 

  1. This is an intent to implement. The main content here is that Vlad and Chris are interested in implementing this functionality. If they implemented it under the names “asdf1”, “asdf2”, and “asdf3”, that would be fine, as long as when the time came to ship, they updated to match the agreed-upon standard.
  2. Getting to an agreed-upon standard is happening; see https://github.com/whatwg/html/issues/1920 . However first we need to resolve a question with other implementers about whether the attribute is tri-state (their proposal) or dual-state (Apple’s proposal). That will undoubtedly affect how it is named, so spending time critiquing their starting names for a tri-state proposal isn’t productive since we don’t even know if we’re going to end up with a tri-state proposal anyway.

 

I’d encourage people to stop worrying about the names. That’s the least-important part of this intent. I appreciate more substantive feedback Addy gave on integration with priority hints, and encourage people to focus on that level of feedback instead.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4d6965de-a7ec-4612-a5ce-14d85c3c5b31%40chromium.org.


Jake Archibald

unread,
Oct 10, 2017, 4:53:37 AM10/10/17
to Vladimir Levin, Domenic Denicola, nekr....@gmail.com, blink-dev, ikilp...@chromium.org, chri...@chromium.org
As a developer, I'm struggling to figure out what this actually does. The doc talks of sync vs async, but <img> is already async due to fetching, so when can it be sync?

I guess there are cases where the img is in the available images cache, is that what it means?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Khushal Sagar

unread,
Oct 10, 2017, 12:27:38 PM10/10/17
to Jake Archibald, Vladimir Levin, Domenic Denicola, nekr....@gmail.com, blink-dev, ikilp...@chromium.org, chri...@chromium.org
On Tue, Oct 10, 2017 at 4:53 AM, 'Jake Archibald' via blink-dev <blin...@chromium.org> wrote:
As a developer, I'm struggling to figure out what this actually does. The doc talks of sync vs async, but <img> is already async due to fetching, so when can it be sync?

I guess there are cases where the img is in the available images cache, is that what it means?

There can be cases where the img is offscreen when it is fetched so when it comes onscreen and the browser has to do the decode work to display it, it is available in the cache and this work gets on the critical path.

Its also possible that the developer is using an onload handler to ensure that the image is fetched before displaying. If the intent is to ensure that the image is painted synchronously with the rest of the content, they can get better performance by using img.decode API.
 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

mkni...@google.com

unread,
Oct 20, 2017, 8:09:47 PM10/20/17
to blink-dev
Addy - to your point, we've found that deferring both image downloads and image rendering until after the above the fold content is a net positive for products. It would be great if this proposal could look at both.

Vladimir Levin

unread,
Nov 22, 2017, 4:54:15 PM11/22/17
to mkni...@google.com, blink-dev
As an update,

We've agreed on "decoding" as the name for the attribute, which would have three different states:
- sync: the user prefers the decode be done synchronously with drawing other content (ie images and text appear together)
- async: the user prefers quick(er) presentation of non-image content followed by asynchronous decode of the image and update later
- auto: the default value where the user agent can decide what to do.

Note that these values are specced as being hints to the user agent.

For additional discussion, please see https://github.com/whatwg/html/issues/1920

Thanks!


On Fri, Oct 20, 2017 at 5:09 PM, mknichel via blink-dev <blin...@chromium.org> wrote:
Addy - to your point, we've found that deferring both image downloads and image rendering until after the above the fold content is a net positive for products. It would be great if this proposal could look at both.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages