Opened 3 months ago
Last modified 6 weeks ago
#59352 assigned defect (bug)
Inline images inserted in the block editor can erroneously get fetchpriority=high
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.5 | Priority: | normal |
Severity: | normal | Version: | 6.3 |
Component: | Media | Keywords: | needs-patch |
Focuses: | performance | Cc: |
Description (last modified by )
I found that inserting an inline image in the block editor can result in it erroneously getting fetchpriority=high
even though it is normally rendered as a small image. When inserting an inline image, the default size (width) is 150 pixels. Nevertheless, the originally uploaded image is actually chosen for the src
(along with its width
and height
) and the user-supplied size is added as an inline width
CSS style. Here is the rendered markup for an inline image appearing as the first image in the content:
<img decoding="async" fetchpriority="high" width="534" height="534" class="wp-image-143" style="width: 30px" src="http://example.org/wp-content/uploads/2023/09/u1f629_u1f973.png" alt="Anguished partygoer emoji" srcset=" http://example.org/wp-content/uploads/2023/09/u1f629_u1f973.png 534w, http://example.org/wp-content/uploads/2023/09/u1f629_u1f973-300x300.png 300w, http://example.org/wp-content/uploads/2023/09/u1f629_u1f973-150x150.png 150w " sizes="(max-width: 534px) 100vw, 534px" />
The fetchpriority=high
attribute is added to this image even when it is immediately followed by an image block with a large size.
To address this, wp_get_loading_optimization_attributes()
could take into account $attr['style']
and parse out any width
property which would override $attr['width']
. This should address inline images from the block editor, but note it would not account for images that are resized by CSS style rules.
Aside: The sizes
attribute here, at least in Twenty Twenty-Three, is causing the full size image to be rendered even though the thumbnail size is included in the srcset
. It seems like whatever the user supplied as the size of the image (e.g. 30px here) should be mirrored between the inline style
attribute's width
and the sizes
attribute. So here it could be sizes="30px"
.
Attachments (3)
Change History (7)
#1
follow-up:
↓ 3
@
3 months ago
It seems to me like the real bug here is that an inline style is being added to control the width of this image instead of updating the width attribute. This also means that WP is incorrectly creating a sizes
attribute based on the width attribute, which is being overridden by the inline CSS.
I'd suggest that we look into fixing the markup generated by the inline image component, rather than adjusting optimizations to take these inline styles into account as a first step.
#3
in reply to:
↑ 1
@
3 months ago
Replying to joemcgill:
It seems to me like the real bug here is that an inline style is being added to control the width of this image instead of updating the width attribute. This also means that WP is incorrectly creating a
sizes
attribute based on the width attribute, which is being overridden by the inline CSS.
Good point. I made a POC plugin to fix up the issue using HTML Tag Processor: https://gist.github.com/westonruter/f37f747a57643462b7efe110dd61d91b
To fix this in core, it seems like this would need to be a special case in wp_img_tag_add_width_and_height_attr()
, yeah?
Anguished partygoer emoji, courtesy of [emoji kitchen] on Google.com