[wp-trac] [WordPress Trac] #53232: Add async decoding attribute as default to the HTML image tags generated by WordPress
WordPress Trac
noreply at wordpress.org
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
More information about the wp-trac
mailing list