Make WordPress Core

Opened 7 months ago

Last modified 3 weeks ago

#59577 assigned defect (bug)

Images in block templates or patterns do not have loading optimization attributes

Reported by: flixos90's profile flixos90 Owned by: adamsilverstein's profile adamsilverstein
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch
Focuses: performance Cc:

Description (last modified by flixos90)

This ticket is created as a break out from #59464: While that ticket was also initially pointing out the lack of loading optimization attributes in TT4, it has been primarily focused on the lack of the dimension attributes width and height from images that are hard-coded in the theme (e.g. in a core/image block within the theme's block templates, template parts, or patterns).

As noted in https://core.trac.wordpress.org/ticket/59464#comment:16 however, there is another arguably more severe problem: Even if that bug was fixed for TT4, most of those images still wouldn't receive the loading optimization attributes. That is because TT4 includes most of its images directly in block templates, or in patterns, outside of template parts, post content, or widget content.

Currently, any images that aren't covered by more specific contexts than template (which is for the overall block template) are not handled at all by wp_filter_content_tags(), impacting TT4 and likely several other block themes. This ticket is focused on that problem, trying to identify a solution to also consider images in the overall block template, while avoiding duplicate processing of images that were already processed with a more specific context.

Change History (14)

#1 @flixos90
7 months ago

  • Description modified (diff)

This ticket was mentioned in Slack in #core-performance by flixos90. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-performance by clarkeemily. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.


4 months ago

#5 @joemcgill
4 months ago

  • Keywords reporter-feedback added

@flixos90 could you clarify how this differs from #59464? After reading through both tickets it was still not clear to me how these two tickets are different. Some examples of how to reproduce the distinct issues would be useful in both tickets.

#6 @flixos90
4 months ago

@joemcgill I tried to clarify that in the last paragraph of this ticket.

#59464 is about images hard-coded in template files missing dimension attributes. Fixing that would still leave some of those images without the image optimization attributes, due to the problem this ticket covers.

This ticket is about wp_filter_content_tags() not adding any image optimization attributes (like fetchpriority and loading) to images that belong to the overarching template (regardless of whether that template comes from a file or from user-generated content in the database).

The reason for that bug is that the template context is used for those images and that context is immediately skipped from any further processing. The original rationale for that was to avoid double processing images (related: #55996) - but it ignores the scenario where there are images as part of the template itself and thus those wouldn't have been processed as part of another context.

I believe this ticket here is notably more severe in its impact than #59464, because it applies to any images in the overarching template. #59464 is only relevant for sites that keep the original template images in their templates, which I don't anticipate to be very common since they are usually considered placeholder images.

Last edited 4 months ago by flixos90 (previous) (diff)

#7 @joemcgill
4 months ago

Thanks @flixos90, I think I understand. This ticket is focused on wp_filter_content_tags() not applying optimizations when we should expect it to, whereas the previous ticket is about addressing use cases where images are added to templates in a way that wp_filter_content_tags() would not be able to process at all. Is that right?

Creating reproduction steps for this ticket could still be useful for others to reproduce the issue and validate an eventual fix.

#8 @flixos90
4 months ago

  • Keywords reporter-feedback removed

@joemcgill Correct. The other ticket is about missing width and height, while this ticket is about any image optimization attributes not being applied to certain images even when they do have width and height.

The problem in this ticket should be relatively straightforward to reproduce:

  • Use a block theme.
  • Use a block template (regardless of whether it originates from a file or database content) which contains images as follows:
    • They either need to have width and height on them, or they need to be in the Media Library and have the wp-image-{id} CSS class so that WordPress can add these attributes automatically.
    • At least 4 images need to be directly in the template, or in a pattern that is referenced from the template. In other words, not within a template part, and not within a post.
  • Note how any of those images that are directly in the template or in a pattern referenced from the template have neither loading="lazy" nor fetchpriority="high" nor decoding="async". This is the problem that needs to be addressed here.
Last edited 4 months ago by flixos90 (previous) (diff)

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


3 months ago

#11 @swissspidy
3 months ago

  • Milestone changed from 6.5 to 6.6

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


2 months ago

#13 @adamsilverstein
3 weeks ago

  • Owner changed from flixos90 to adamsilverstein

I'll take ownership of this one @flixos90 since I know you are away for most or all of the the 6.6 release cycle

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


3 weeks ago

Note: See TracTickets for help on using tickets.