Opened 12 months ago
Last modified 4 months ago
#59577 assigned defect (bug)
Images in block templates or patterns do not have loading optimization attributes
Reported by: | flixos90 | Owned by: | adamsilverstein |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Media | Keywords: | needs-patch |
Focuses: | performance | Cc: |
Description (last modified by )
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 (18)
This ticket was mentioned in Slack in #core-performance by flixos90. View the logs.
12 months ago
This ticket was mentioned in Slack in #core-performance by clarkeemily. View the logs.
12 months ago
This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.
9 months ago
#6
@
9 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.
#7
@
9 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
@
9 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
andheight
on them, or they need to be in the Media Library and have thewp-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.
- They either need to have
- Note how any of those images that are directly in the template or in a pattern referenced from the template have neither
loading="lazy"
norfetchpriority="high"
nordecoding="async"
. This is the problem that needs to be addressed here.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
8 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
8 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
7 months ago
#13
@
6 months 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.
6 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
5 months ago
This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.
4 months ago
#17
@
4 months ago
- Milestone changed from 6.6 to Future Release
Moving this to future release while we continue work on this issue.
@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.