[wp-trac] [WordPress Trac] #58681: No lazy loading attribute on images in gallery

[WordPress Trac]

#58681: No lazy loading attribute on images in gallery
--------------------------+--------------------------
 Reporter:  spacedmonkey  |       Owner:  flixos90
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.4
Component:  Media         |     Version:  5.5
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |     Focuses:  performance
--------------------------+--------------------------
Changes (by flixos90):

 * keywords:  has-patch => 2nd-opinion
 * owner:  thekt12 => flixos90
 * version:  trunk => 5.5
 * milestone:  6.3 => 6.4


Comment:

 @spacedmonkey @thekt12 @joemcgill I have researched this bug further. I
 think the problem is not the context used, and it's also not caused by
 [55825]: While [55825] technically caused this to seem broken, the
 implementation was already flawed before. [56037] also included a minor
 unintended change that broke what [55825] solved. Let me break it down
 because this is quite complex and there are several issues here.

 * The biggest problem is that `do_shortcode()` runs on `the_content` with
 hook priority 11, which is ''after'' `wp_filter_content_tags()` (default
 priority 10). This is problematic because it means the intended function
 to parse images in post content runs too early to affect images added via
 shortcodes. This has been wrong all along and really is the root of the
 problem.
 * [55825] ensured that programmatically included images ''within'' post
 content were only modified when considered as part of the whole content
 blob, i.e. the `the_content` context. Yet, that didn't consider images
 from shortcodes, which technically caused this to seem broken. However,
 this was broken all along since even before [55825] images in a shortcode
 would be treated separately from other in-content images, which is
 problematic e.g. when the shortcode is at the beginning of the post
 content: Any other images in the post content would be counted before
 images in the shortcode were counted, meaning that the shortcode images
 would all get `loading="lazy"` even if they shouldn't.
 * [56037] introduced a very small bug that partially reverted [55825]:
 Images in `the_post_thumbnail` or `wp_get_attachment_image` contexts
 shouldn't be handled when the `the_content` filter is running (i.e. not
 modify/add any attributes), but after [56037] they may now add
 `fetchpriority="high"`.

 Out of the above, the only clear and trivial course of action is to fix
 the regression that [56037] reintroduced after [55825] addressed it.
 That's a one-line change in the `doing_filter( 'the_content' )` clause.
 I'm going to address that shortly.

 For a holistic fix, I could see us doing one of two things:
 * Either we change the hook priority of `wp_filter_content_tags()` on the
 `the_content` filter to something later, e.g. `12`. That would resolve the
 issue holistically. However, it may have unintended side effects on the
 plugin ecosystem so should be approached with caution.
 * Or we decide that for shortcodes it is their own responsibility of
 handling loading optimization attributes.

 Either of the above are changes that don't fit into the scope of 6.3, both
 because they are too broad and because the root issue here was introduced
 as long ago as when `wp_filter_content_tags()` was added (WP 5.5).

 Other than that, what we ''could'' do is ensure that the `doing_filter(
 'the_content' )` clause is only entered if the current hook priority
 (`$GLOBALS['wp_filter']['the_content']->current_priority()`) is anything
 before `10`, i.e. before `wp_filter_content_tags()`. That would revert the
 behavior to what it was before, but it wouldn't make it any less faulty.
 Since lazy-loading too much can have more severe implications on load time
 performance / LCP than lazy-loading too little, I don't think we should
 reintroduce that bug. Either way, none of those two options would be a
 proper fix. Another reason to not reintroduce the previous behavior would
 be that both of the two more holistic proposals above would require that
 programmatically injected images in post content are never touched outside
 of the `the_content` context.

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