[wp-trac] [WordPress Trac] #53232: Add async decoding attribute as default to the HTML image tags generated by WordPress

Fri Feb 25 15:45:47 UTC 2022

#53232: Add async decoding attribute as default to the HTML image tags generated by
WordPress
--------------------------------------+-----------------------------
 Reporter:  isaumya                   |       Owner:  (none)
     Type:  feature request           |      Status:  new
 Priority:  normal                    |   Milestone:  Future Release
Component:  Media                     |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+-----------------------------

Comment (by mihai2u):

 Hi,

 I've spent time on this, and this was my thought process doing the
 research to confirm the viability of this addition and potential edge-
 cases.

 **Scenario with the biggest benefit, huge images**

 Tested these here:
 https://files.urldocs.com/share/test-async-on/test-async-on.html
 https://files.urldocs.com/share/test-async-off/test-async-off.html

 Before running this test, I've ran this without a decoding attribute, and
 in tests I've discovered the default state of auto was triggering the
 decoding of the image on its own thread automatically due to the
 heuristics in Chrome.
 This is something that came in newer versions of the browser, as it was
 not the case a half a year ago.
 That is why for the tests to have a confirmation that we're testing sync
 vs async decoding, for the 'off' tests, I've included the attribute of
 decoding="sync", otherwise the tests (webpagetest, lighthouse, gpsi were
 yielding the same result in both scenarios).

 the webpagetest results, running this 9 times for first view only:
 https://webpagetest.org/result/220224_BiDc0D_D7J/
 https://webpagetest.org/result/220224_BiDc0D_D7J/

 There is no difference (or negative impact) on the LCP with the presence
 of async or sync decoding. The only measurable difference is in the Total
 Blocking Time increasing when decoding is setup to sync due to the long
 running task decoding the image on the main thread.

 Adding decoding sync did not block the rendering of the text underneath it
 (according to the specs this is what I expected to see, but was not the
 case), so this isn’t a benefit after all with current browsers

 Decoding async still shows the progressing loading of a webp / jpg, as it
 comes through the network, with no perceivable difference using one
 decoding setting over the other.

 Conclusion: No negative impact on LCP. Positive impact on interactivity.
 Progressive loading is working and consistent with both decoding options.

 **Animated Images**

 Spec: “Animated images will become completely available only after all
 their frames are loaded. Thus, even though an implementation could decode
 the first frame before that point, the above steps will not do so, instead
 waiting until all frames are available.”
 ( https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-
 decoding )

 Gif with decoding sync: https://files.urldocs.com/share/test-async-off-gif
 /test-async-off-gif.html
 Gif with decoding async: https://files.urldocs.com/share/test-async-on-gif
 /test-async-on-gif.html

 I've used global network throttling to test this one on most popular
 browsers on OSX.
 https://www.npmjs.com/package/@sitespeed.io/throttle

 As per the test, can confirm that with or without decoding async, the
 first frame of the gif is displayed just as quick, and as frames keep
 being downloaded, they're rendered sooner, before completing the download
 of all of the frames, which is an unexpected (positive though) difference
 vs. the spec on Safari, Firefox & Chrome.

 Conclusion: async decoding on Gifs does not produce negative consequences.

 **Large images without width/height**

 Spec: Decoding sync indicates a preference to decode this image
 synchronously for atomic presentation with other content.

 Because of this, I was afraid adding decoding async on large images that
 don't have width/height attributes defined would have a negative impact
 with layout shifts introduced.

 Tested these here:
 https://files.urldocs.com/share/test-async-on-webp-no-size/test-async-on-
 webp-no-size.html
 https://files.urldocs.com/share/test-async-off-webp-no-size/test-async-
 off-webp-no-size.html

 In either scenarios, with CPU & network throttling enabled, the text below
 the images was rendered in the correct spot in either scenarios.

 Conclusion: No layout shift introduced by using decoding async on above
 the fold images.

 **Vector graphics**

 Spec: If decoding does not need to be performed for this image (for
 example because it is a vector graphic), resolve promise with undefined.

 Tested this here:
 https://files.urldocs.com/share/test-async-on-svg/test-async-on-svg.html
 https://files.urldocs.com/share/test-async-off-svg/test-async-off-svg.html

 The results here were surprising, as I was expecting there would be no
 difference, but I've noticed varying results with total blocking time
 increasing due to decoding times (and othertimes yielding 10ms)
 https://pagespeed.web.dev/report?url=https%3A%2F%2Ffiles.urldocs.com%2Fshare
 %2Ftest-async-off-svg%2Ftest-async-off-svg.html
 https://pagespeed.web.dev/report?url=https%3A%2F%2Ffiles.urldocs.com%2Fshare
 %2Ftest-async-on-svg%2Ftest-async-on-svg.html

 Conclusions: There is no difference when including async decoding on SVG
 graphics, while based on the spec, it might be better to avoid adding a
 decoding async attribute on these type of image tags.

 **Many images, not lazy loaded**

 Included many images using async decoding vs. sync decoding to have a test
 scenario with a normal scenario where there's more images present on a
 page.

 https://files.urldocs.com/share/test-async-on-many/test-async-on-many.html
 https://files.urldocs.com/share/test-async-off-many/test-async-off-
 many.html

 **Past experience**

 We, at XWP, have defaulted to adding the async decoding for images on all
 projects for more than a year now, and this was based on the research on
 the positive impact on interactivity we've confirmed.

 **Next steps**

 TL;DR: Explored several edge-cases in order to find potential downsides
 from including this attribute. Used webpagetest, GPSI & local lighthouse
 tests for all tests to confirm conclusions. Used performance profiling to
 go deeper and confirm the data/conclusions when the results were too
 consistent in the lab tests.

 A big thumbs-up for this to be the default option for all images, not just
 the ones in the_content.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53232#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform