Update `the_content` with the correct image format

[mitogh]

Feature Description

Once an image attachment has more than one type of image available we need to make sure the correct images are rendered:

Scenario 1 - Render WebP by default

• If the requested browser support WebP continue with the flow, otherwise render a JPEG version.
• If the attachment has a WebP version of the image replace any JPEG version with the exact WebP version of the image.
• If no WebP version exists keep serving the JPEG version

Scenario 2 - Render JPEG version

• If the browser does not accepts WebP version render a JPEG version
• if the current attachment does not have an exact WebP version for the requested image deliver the JPEG version
• If the WebP is disabled via a filter keep rendering JPEG by default.

This filter would be placed in the_content so when the article or articles are rendered the delivered content to the users uses the appropriate image format.

This work is a subsequent step for:

• When uploading, generate both WebP and jpeg format images by default #142

[felixarntz]

@mitogh

If the requested browser support WebP continue with the flow

I thought the idea was to always load WebP in the frontend (if the image exists in that version), based on the previous discussions on the Slack chat and the decision made in #96 (comment)

We decided to keep generating JPEG versions not for the frontend, but for other usages that are more niche but relevant, e.g. email newsletters.

In other words, I don't think we need to worry about scenario 2 here - we can rely on WordPress core's definition of officially supported browsers, all of which support WebP.

[mitogh]

Correct @felixarntz , the main idea would be to render WebP by default, if the browser supports it which is the majority of browsers at this point but for the cases where the browser does not support WebP the JPEG version would be displayed instead. By doing this we allow displaying the image at all times for older and more modern browsers, and this does not require a lot of extra work as is just checking against the HTTP_ACCEPT header which I think is a great benefit so modern and older browsers can still work as they are where modern browsers would take the WebP version by default (as WebP is supported there).

For example, if we load WebP by default this is how it would look in Safari when this validation is not present.

And this is how it looks when the validation is present, the JPEG version is loaded instead.

And for modern browsers, a WebP version is loaded instead.

One of the major problems with this approach is the fact when using cache mechanics Which stores the full HTML of the page we won't able to detect this header from the client (Browser) so in that case, WebP would be loaded all the time, but a filter would be in place as described in #96 (comment) to change this behavior.

[adamsilverstein]

Note that the intention in in #142 will be to store the default 'sizes' as WebP, so these would automatically be used for the srcset attributes. The one exception is the "full" sized image referenced in the src attribute, we need to ensure this uses the WebP file as well, currently this still references the original uploaded jpeg or -scaled version of the jpeg.

I'm also wondering whether an output mime type filter makes sense, since we plan to store WebP and jpeg versions, it should be possible to switch the default output type at any time (as long as the files are available).

[mitogh]

Created a PR with the implementation in place to replace the_content

• Update the_content with the appropiate image format #152

[felixarntz]

Thanks @mitogh for the clarification. Overall what you're suggesting makes sense to me, relying on the Accept HTTP header. However, as you're already saying, this will have a problem with cached content. How will we be able to reliably know whether a request to the server will later be cached or not? Let me elaborate:

• Imagine a request comes through to WordPress from a browser that doesn't support WebP per its Accept header.
• WP will recognize that and not serve WebP.
• Since the site has a caching layer, the content is now cached, serving JPEG to all sites at least until that cache is invalidated.

The above would not be what we want, so how can we prevent that?

[mitogh]

Great point @felixarntz so the idea would be to add a filter inside of the plugin like this:

add_filter( 'wp_preferred_image_mime', function() {
     return 'image/webp';
} );

Applied here https://github.com/WordPress/performance/pull/152/files#diff-71ed188a16b79d179868ee80e76f775462a451e871fc3d6214fcacca3edcea8cR356 that would deliver WebP all the time in the content.

[felixarntz]

@mitogh I understand the code, but as far as I can tell it doesn't solve the problem from the scenario I mentioned above. Could you please double-check?

[mitogh]

Right in this scenario, we have 2 options:

1. Always deliver an image format as described in Store previous image size before WebP conversion #96 (comment) which can be accomplished with Update the_content with the correct image format #149 (comment) so that would deliver WebP all the time, which would be the default behavior in the plugin, deliver WebP regardless. This would be used for the scenario you described so even if the page is cached the WebP image would be cached as part of the markup.
2. Another path is to leave this dynamic removing this filter Update the_content with the correct image format #149 (comment) this would deliver the best possible image when the page is delivered.

I think those 2 cases cover the majority of use cases:

• Enable WebP by default
• Use WebP if full HTML cache is in place
• Dynamically determine the best image format when Cache is not present
• Delivery only a JPEG instead of WebP

In regards to your specific use case described #149 (comment) would fall into Use WebP if full HTML cache is in place at least not from the server.

We could introduce a JS piece of code to review if the client supports WebP if the client does not support WebP we replace the src of the images with a JPEG version in order to be compatible as much as possible with the clients.

Let me know what do you think about this approach so I can explore some alternatives for this by enqueueing an inline JS to see how we can make this happen. Let me know in case you have additional questions. @felixarntz

[felixarntz]

@mitogh I see, so you're saying that developers would need to use the filter to enforce WebP to show on sites with page caching, to avoid JPEG being served just because whichever request caused the cache to be populated was from a browser that didn't support WebP, correct?

In that case, I don't think that would be a solution we should strive for, since it would require developer intervention to serve WebP in a use-case that is quite common. Caching layers are very common on WordPress sites, and unfortunately we cannot control them from WP core.

That's why I'm still leaning towards using WebP unconditionally by default, since the Accept header doesn't come through caching and therefore is unreliable. Is the primary concern about doing that Safari?