Update the_content with the appropiate image format

[mitogh]

Summary

Uses image/webp if supported by the client and updates the image/jpeg, image/jpg formats with the modern format if available.

References in the content are updated with the WebP format if available.

Fixes:

• Update the_content with the correct image format #149

Related with:

• Create image sub-sizes in additional MIME types using sources for storage. #147

Relevant technical choices

Checklist

• PR has either [Focus] or Infrastructure label.
• PR has a [Type] label.
• PR has a milestone or the no milestone label.

[adamsilverstein]

This worked well in my testing across a variety of themes. The only issue I noticed was when inserting an image at the "large" size with a large image upload that results in a -scaled image, the jpeg is used for the image src, since the webp version isn't available yet (see #174).

[mitogh]

Thanks for taking the time to test it, currently this is expected and described here:

performance/modules/images/webp-uploads/load.php

Lines 414 to 417 in 7b38de8

	if ( isset( $metadata['file'] ) && strpos( $url, $basename ) !== false ) {
	// TODO: we don't have a replacement for full image yet, issue. See: https://github.com/WordPress/performance/issues/174.
	continue;
	}

Based on the decision from:

• When generating WebPs, ensure full size is generated(-scaled for large images) #174

The code would be updated accordingly if required.

[felixarntz]

@adamsilverstein

This worked well in my testing across a variety of themes. The only issue I noticed was when inserting an image at the "large" size with a large image upload that results in a -scaled image, the jpeg is used for the image src, since the webp version isn't available yet (see #174).

I noticed that as well, it depends on the viewport size and pixel density. Since we currently don't have WebP versions for the "full" size (whether -scaled or original), it's best to currently test this PR on a mobile viewport since there it's most likely to get served a WebP image.

The problem is that most modern screens have a high pixel density like @2x, which means if I look at an image of 600px (or more accurately in a viewport of 600px), the browser will look for a size >=1200px, which would already be more than WordPress core's large by default.

If you want to test this more specifically without the above caveats, you can put a temporary filter in place to ensure WordPress never chooses a size greater than the image size you actually specified (which may cause blurry images on larger or high-density devices though):

add_filter(
	'wp_calculate_image_srcset',
	function( $sources, $size_array ) {
		foreach ( $sources as $index => $source ) {
			if ( 'w' === $source['descriptor'] && $source['value'] > $size_array[0] ) {
				unset( $sources[ $index ] );
			}
		}
		return $sources;
	},
	10,
	2
);

There's certainly room for optimization in core's default behavior there, but that's a separate rabbit hole :)

Right, this answers that question for me - we need the full size webp available for the correct markup when users select the full size image.

I agree this gives us an answer for #174, that we should also generate a WebP version of the full size.

[felixarntz]

@mitogh Great! I left a few follow-up comments, mostly minor though. This is almost ready.

[felixarntz]

This one open discussion is the only thing we need to finalize before we can merge this.

[mitogh]

Thanks, @felixarntz just updated to code to follow what WP Core uses in order to reduce the friction in the scenario this would be merged into WP Core.

Let me know in case you have any additional feedback.

[felixarntz]

Awesome work @mitogh!

[adamsilverstein]

Code looks great to me, thanks for the structural changes that will make prepping this for core more straightforward. Also retested and everything worked well in my testing.