Images: repeating a single image causes `fetchpriority` to be repeated

[adamsilverstein]

I noticed a small bug in how core auto-applies the fetchpriority="high" attribute. This feature aims to add this attribute only to the LCP image, which is frequently the first large image in a layout.

The bug is this: if a user inserts a single image several times, every instance of the image will have the fetchpriority="high" attribute.

Steps to reproduce

1. create a new post
2. insert a large image at the top of the post
3. Insert the image several more times, so the post now contains several copies of the image.
4. save and view the post source code

Expected result:
The first large image contains the fetchpriority="high" attribute.

Actual results:
Each copy of the image contains the fetchpriority="high" attribute.

Notes

I am posting this here because it feels like a bug, even though I'm not sure we should fix it:

• The image URL for each item is the same so there may be zero impact to repeating the attribute (the same URL is prioritized). Unless there is a case where the actually fetched image from the srcset could be different for two copies of the same image?
• There could be a slight negative performance impact when fixing this since the repetition is the result of an optimization where we only consider each unique image once.

[felipeelia]

I found this one so interesting that took a minute to investigate why this was happening. Here are my findings:

This happens due to the logic applied in ​wp_filter_content_tags(). First, we run a regex to get all <img>s and <iframe>s, then all the images blocks. Then we go over all the <img> but on
​this line we avoid changing the same image twice. As we've applied the attribute in the first one, it'll be applied to all the others.

[adamsilverstein]

this line we avoid changing the same image twice. As we've applied the attribute in the first one, it'll be applied to all the others.

Exactly! thanks for linking to the code that does this.

[afercia]

Unless there is a case where the actually fetched image from the srcset could be different for two copies of the same image?

Question: what would happen in the following scenario?

• A page layout is made of a wide area at the top of the page, typically a header.
• The page content below lives in a narrower column.
• The image is added a first time within the wide header.
• The same image is then added multiple times in the narrower column of the content (or a sidebar, for example).

Would the actually image fetched by the browser be different in this case?

[joemcgill]

I'm moving this into the 6.5 milestone for further investigation. This may seem unexpected, but was in fact an intentional decision as I understand it, so we may end up closing this as a wontfix. For a use case like @afercia outlines above, I believe browsers will use the larger image from the srcset that it already fetched for the subsequent img tags rather than fetching a smaller file, which is the same behavior that browsers will use if it already has a larger that needed file from the source list in cache, but worth confirming.

It would also be worth seeing what the real performance impact of removing the optimization would be, since this is likely an edge case optimization anyway.

[swissspidy]

Punting to 6.6 since there is no activity, patch, nor an owner. Feel free to move back to 6.5 if there's a patch ready.

[adamsilverstein]

Moving this to Future Release as we continue investigating, this likely has a very small impact overall so can be considered low priority.