Inline images inserted in the block editor can erroneously get fetchpriority=high

[westonruter]

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".

[westonruter]

Anguished partygoer emoji, courtesy of [emoji kitchen] on Google.com

[westonruter]

Selecting an inline image from paragraph block in block editor

[westonruter]

After inserting an inline image with initial size set to 150px

[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.

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.

[westonruter]

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?

[flixos90]

Tentatively moving this to the 6.5 milestone for further investigation.

[flixos90]

I agree that the root of the problem is in the inline image component in Gutenberg. That said, it could be fixed either way. The existing wp_img_tag_add_width_and_height_attr() function was originally introduced as a fallback to add missing dimension attributes already partly because Gutenberg wasn't always adding those attributes, so I think adding a special condition for this use case could work.

Doing it in that function is also more reliable as it will address the problem for existing content, while doing it in Gutenberg would likely only fix it for new content created in the future.

See https://core.trac.wordpress.org/ticket/59352#comment:3: This adds an extra condition to wp_img_tag_add_width_and_height_attr() which ensures the dimension attribute respects an enforced width via style attribute.

Trac ticket: https://core.trac.wordpress.org/ticket/59352

I just tested this PR with Playground and it worked. Wow, that is a nice way to test.

Editor:

Post content:

This is inline: [[Image(https://i0.wp.com/playground.wordpress.net/scope:0.6233595411696027/wp-content/uploads/2023/12/anguished-partygoer.png)]]

Frontend HTML:

This is inline: [[Image(https://i0.wp.com/playground.wordpress.net/scope:0.6233595411696027/wp-content/uploads/2023/12/anguished-partygoer.png)]]

The width and height attributes are added.

@westonruter @joemcgill I just added test coverage (see updated PR description). Given you already approved, I'm planning to commit this tomorrow, but please take a look at the tests if you can.

[flixos90]

In 57294:

Media: Consider inline image CSS width to backfill width and height attributes.

Prior to this changeset, WordPress core would use the original image size, which in the particular case of inline images would be severely off, as they are usually very small. This could lead to incorrect application of fetchpriority="high" and other performance optimizations.

Props westonruter, flixos90, joemcgill, mukesh27.
Fixes #59352.

Committed in https://core.trac.wordpress.org/changeset/57294

[audrasjb]

In 58033:

Media: Prevent division by zero in wp_img_tag_add_width_and_height_attr().

This changesets adds a check for $size_array values to prevent a potential division by zero.
Follow-up to [57294].

Props jdekhtiar.
Fixes #61054.
See #59352.