[wp-trac] [WordPress Trac] #58631: decoding="async" is added wildly, even if loading="eager" is there

[WordPress Trac]

#58631: decoding="async" is added wildly, even if loading="eager" is there
-------------------------------+------------------------------
 Reporter:  vyskoczilova       |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Media              |     Version:  6.1
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  performance
-------------------------------+------------------------------
Changes (by westonruter):

 * keywords:   => reporter-feedback
 * focuses:   => performance
 * component:  General => Media
 * version:  6.2.2 => 6.1


Comment:

 @vyskoczilova Hi! Just seeing this ticket now. I learned about your blog
 post [https://kybernaut.cz/en/clanky/the-unintended-consequences-of-
 decodingasync-on-your-wordpress-sites-lcp/ The Unintended Consequences of
 decoding=’async’ on Your WordPress site’s LCP] and then this ticket from a
 [https://wordpress.org/support/topic/decodingasync-2/ support topic] from
 @guillermo77 for the Image Prioritizer plugin. I left a comment on the
 support topic, but it is held in moderation, so I'll reproduce it here.

 I did some benchmarking with the Twenty Twenty-One theme with a desktop
 viewport (1350×940) on a post singular view there is an Image block at the
 beginning of the content with “Full width” alignment so the largest image
 size will be used. I used LocalWP for my test environment. By default,
 WordPress renders this on the frontend as:

 {{{
 <img
   fetchpriority="high"
   decoding="async"
   width="1024"
   height="668"
   src="http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-1024x668.jpg"
   alt=""
   class="wp-image-7"
   srcset="
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-1024x668.jpg  1024w,
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-300x196.jpg    300w,
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-768x501.jpg    768w,
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-1536x1002.jpg 1536w,
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-2048x1336.jpg 2048w,
     http://localhost:10048/wp-
 content/uploads/2025/01/American_bison_k5680-1-1568x1023.jpg 1568w
   "
   sizes="(max-width: 1024px) 100vw, 1024px"
 >
 }}}

 Note the `fetchpriority=high` here which is correct since it is the LCP
 element. I also added a plugin to this site to allow manipulation of the
 `decoding=async` via a query parameter:

 {{{#!php
 <?php
 if ( isset( $_GET['add_decoding_attr'] ) ) {
         add_filter(
                 'wp_img_tag_add_decoding_attr',
                 static function () {
                         return rest_sanitize_boolean(
 $_GET['add_decoding_attr'] );
                 }
         );
 }
 }}}

 Then I used the [https://github.com/GoogleChromeLabs/wpp-
 research/tree/main/cli#benchmark-web-vitals benchmark-web-vitals command]
 to make 250 requests to the URL with `decoding=async` removed and 250
 requests with it added.

 With a file `decoding-async-urls.txt`:

 {{{
 http://localhost:10048/lcp-image/?add_decoding_attr=false
 http://localhost:10048/lcp-image/?add_decoding_attr=true
 }}}

 I ran this command:

 {{{
 npm run research -- benchmark-web-vitals --number=250 --file=decoding-
 async-urls.txt --output=csv --window-viewport=desktop --show-variance
 --show-percentiles
 }}}

 See the results in this
 [https://docs.google.com/spreadsheets/d/1VzWsFCDbkdAggZ_DK4p1VldbihkcgZYT7IIIMO7xwss/edit?gid=433241203#gid=433241203
 Google Sheet]. You can see from the results that the median LCP-TTFB
 metric (highlighted in bold) shows that **adding `decoding=async` actually
 ''improves'' (reduces) LCP by 6.7%**. Without the attribute the metric was
 72.95 ms, when the attribute was added the LCP decreased to 68.05 ms.
 (Note this "TTFB-LCP" metric just subtracts TTFB from the LCP so that
 variations in TTFB are ignored from the metric.)

 See also the original
 [https://core.trac.wordpress.org/ticket/53232#comment:34 investigation] by
 @mihai2u on the Trac ticket (#53232) for adding decoding=async by default
 where he found no negative impact when this attribute is added to the LCP
 IMG element. (Hey!)

 Could you share more details about how you are seeing that
 `decoding=async` is negatively impacting your LCP? Can you provide some
 similar benchmarks and a test case to reproduce the issue?

 If there is conclusive evidence that adding `decoding=async` hurts LCP
 performance, then core definitely should not be adding this to the `IMG`
 it adds `fetchpriority=high` to (in the same way it omits `loading=lazy`).
 However, we haven’t seen this to be the case.

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