Investigate email client support for WebP, plugin usage

[adamsilverstein]

WordPress now supports WebP images, and this plugins webp-uploads module explores using WebP as the default sub size image format. During testing with WebP, one issue raised was support for the WebP format in email clients.

Using WebP images in emails

According to Can I Email (at the time of this writing) support is very good, with >97% supporting either directly or by converting WebP images to JPEGs. However, one important exception is Outlook on Windows which does not support WebP.

Because WordPress sites can use their media library as the source of images when sending emails, for example newsletters - see https://wordpress.org/plugins/search/newsletters/ - we need to ensure we examine this issue.

Questions:

• Where do top newsletter plugins get their image URLs from? If RSS feed for example, can we keep the original (JPEG) images there in all cases?
• Is there a way to create emails that fall back to the original for non supporting clients (eg picture element)?
• How many Outlook on windows clients still vs outlook.com? caniemail suggests <3% so maybe sites can opt out if needed?
• Should we consider generating an additional medium-large image in the original (JPEG) format for use by email clients when the default output is changed to WebP so they don't have to use the original image?

[adamsilverstein]

Question to investigate: how do email clients handle image markup when the img src references a jpeg (the original) and the srcset references WebP (the sub sizes), for example the markup in the description of https://github.com/WordPress/performance/issues/69?

[adamsilverstein]

Hey @dainemawer - are you still looking at this issue? Would love to hear your finding about WebP email support.

[dainemawer]

@adamsilverstein I am indeed! I have taken a look, I just need to compile my findings - I will most certainly update this ticket today if not tomorrow!

[dainemawer]

Hey @adamsilverstein I took a pretty detailed look into this ticket, here are my findings:

• First off, I fired off emails using: https://app.postdrop.io/ which is a free service for sending HTML emails.
• I then reviewed Can I Email to see what the support for WebP was like.

WebP Support

The general support sentiment is this:

• Apple Mail (macOS + iOS) full support for WebP in v14
• Gmail (Desktop, iOS, Android etc) all have partial support, if a WebP file is discovered by the email client, it will convert it to a jpeg. This seems like a pretty acceptable solution to me.
• Outlook has no support for WebP through its Email client on Windows, however the latest versions of Windows Mail, Outlook for Mac, Outlook.com, iOS and Android are all very well supported.
• There are of course some outliers like Thunderbird, Samsung Email, Proton and Hey whose latest versions all have WebP support.

Can I Email reckons overall there is a 85.30% support rate, with an additional 11.8% for partial support in the market. Pretty decent.

Src and Sizes Support

• I then took a look at srcset and sizes attributes support. Unfortunately this leaves a lot to be desired.

The general support sentiment is this:

• Apple Mail on MacOS and iOS is fully supported.
• Gmail has no support.
• Outlook has no support, other than Outlook for Mac
• Outliers like Samsung Email and Mozilla Thunderbird have full support.

Can I Email reckons there is an overall support rate of 33.33%

Tests

Anyway! I decided to test this out. As I cannot get debugging information from apps like Gmail or Mail on iOS. I opted to test in MacOS Mail on Desktop, the Gmail iOS App and Gmail in the browser. Here are my findings:

To start I tested the following markup:

<tbody>
      <tr>
          <td><img src="https://i.ibb.co/JvJCSHv/microsoft-365-y5y-Irf-ZXNHg-unsplash.webp" alt="Some WebP Image"></td>
     </tr>
</tbody>

Results

---

• Apple Mail rendered the .webp image, no problem
• Gmail on iOS renders the .webp image too, assuming it converts the image to a jpeg like the browser client.
• Gmail in the browser also renders the image, but looking at the Network panel, the image comes across the wire as a jpeg

Okay, so second test, lets try responsive images.

I tested with the following markup:

<tbody>
      <tr>
          <td><img src="https://i.ibb.co/GsxQ7CJ/microsoft-365-y5y-Irf-ZXNHg-unsplash.jpg" srcset="https://i.ibb.co/JvJCSHv/microsoft-365-y5y-Irf-ZXNHg-unsplash.webp 1024w" sizes="100vw" alt="Some WebP Image"></td>
     </tr>
</tbody>

Results

---

• Apple Mail renders the srcset and sizes images - hard to tell which image was actually rendered. I can verify that the markup was not amended or changed by looking at the "Raw Source" of the image.
• Gmail in the browser strips out the srcset and sizes attribute and resolves to using the src attribute value on a non-responsive image tag.
• The Gmail app still renders the image, but again, hard to tell which one actually rendered.

I took one more stab at this to see if I could get some more accurate results

<tbody>
      <tr>
          <td><img src="https://i.ibb.co/GsxQ7CJ/microsoft-365-y5y-Irf-ZXNHg-unsplash.jpg" srcset="https://i.ibb.co/t2n84V0/art-320.webp 320w, https://i.ibb.co/W0bShWd/art-1024.webp 1024w" sizes="(min-width: 1024px) 50vw, 100vw" alt="Some WebP Image"></td>
     </tr>
</tbody>

Results

---

• Apple Mail rendered the same, theres no refresh so the image did not respond in size.
• Gmail on both the browser and iOS stripped out any responsive features and just rendered the src attribute value on the image.

[adamsilverstein]

@dainemawer Excellent, thanks for doing this research! We need to document this limitation in a dev note, so this issue will be a good reference.

A follow up item here would be to investigate existing email plugin integrations (eg MailChimp) to see where they pull their images from (RSS feed?). Then we could either automatically provide a jpeg there, or at least provide a way plugins can get one. I will create a follow up issue.

[dainemawer]

@adamsilverstein - so this has been leading me down a bit of a blurry rabbit hole. Based on some research I've basically identified 3 types of email plugins:

1. Some provides server email alternatives to that of wp_mail - for instance SendGrid
2. Others like MailChimp for WordPress only really handles the tight-coupling through API's of subscription forms and lists.
3. The odd one or two allow for building custom HTML newsletter templates from within the WP Dashboard. These plugins, for the most part rely on WP API's like wp_get_attachment_image_src - I think in this case we'd be okay if we're updating core functions?

MailChimp does offer a service like: https://mailchimp.com/features/rss-to-email/ - however MailChimps Studio Editor doesn't support webp - meaning two things:

• If you were building an HTML email through MailChimp you couldn't serve an image in webp.
• In order for images to pull through on MailChimps side, we'd need to update the core RSS feed functionality to support the featured image of posts. It appears unknown if MailChimp would support these images in webp. Im assuming not if they only allow a small list of image formats to be uploaded by users.

There are some plugins around like https://www.mailerlite.com/features/rss-to-email - which essentially makes featured images available in the RSS feed.

This leaves us in a bit of a strange position mainly because:

1. Should we be supporting images by default in Core for RSS / Atom Feeds - in order to consider those who fire off RSS-To-Email features?
2. It's kinda difficult to get stats on which email clients, subscribers of a list or RSS feed are using, so understanding support for WebP in that case could be greatly skewed compared to that of the greater internet.
3. Even so, I would think that this feature would need to account for either 2 separate RSS feeds (one .jpg, one .webp) as RSS feeds are consuming by many varying platforms from email to electron apps.

To me it seems like considering the variability, we should stick with JPEG in this regard.

[adamsilverstein]

Even so, I would think that this feature would need to account for either 2 separate RSS feeds (one .jpg, one .webp) as RSS feeds are consuming by many varying platforms from email to electron apps.

Thanks for the research here @dainemawer...

Good point, RSS feeds are also used as podcasting feeds, and podcast readers can display rich media including images, so again JPEG might be better to use here.

We should dig in a little more for the exact approach; I think we should:

• Default to the jpeg mime type version for the RSS feed output when available
• Ensure RSS image calls are readily filterable (the feed is already, but there may be room to add something image specific)

[dainemawer]

Makes sense @adamsilverstein - I'll take a stab at an approach tomorrow :)

[dainemawer]

@adamsilverstein - so based off of some further research, it sounds like there is a bit of work to do here:

WordPress Feeds

As we know, WP supports multiple feeds: RSS, RSS2, RDF and Atom. Im not entirely sure what the main differences are, but Im guessing if WP supports it in core, we should ensure the functionality remains intact.

Hooks / Filters

There are a number of hooks and filters we can tap into: https://developer.wordpress.org/?s=rss&post_type%5B%5D=wp-parser-hook

Im not 100% sure as to why WP does not include featured images by default in feeds, but I wonder if this could be as simple as something like:

add_filter( "wp_feed_featured_images", "__return_true" );

• Maybe thats all thats needed? We can handle the mime type support under the hood?
• We can handle any feed specific defaults - like image/jpeg using is_feed => https://developer.wordpress.org/reference/functions/is_feed/
• We'd also need to most likely exclude comment feeds from this functionality?

The other option, of course is to add a custom hook into the feed templates, something like do_action( "rss_featured_image" ) though Im not sure how much a feature like this deviates into Core as opposed to performance.

Maybe Im approaching this wrong, but its a start!

[bethanylang]

Removed Needs Dev and added Needs Discussion as it sounds like this issue is really just about the investigation of the approach for now. Once we decide on an approach, we can either change its title or close this one out and create a new issue for implementation.

[adamsilverstein]

@dainemawer I tested this with our current code approach which keeps jpeg images in the same meta/data locations they are currently generated, and adds WebP to output by rewriting the_content on the fly. In the default mode this means things like feeds continue to use the JPEG versions we also generate.

A few things to consider for this ticket going forward:

• When we work on adding mime type support to core functions in https://github.com/WordPress/performance/issues/155 we should consider ensuring jpeg remains the default
• Developers can switch the approach to only generating WebP sub-sizes, in that case we should make it clear to developers they may have issues with sending emails with only WebPs
• Email plugin developers should be able to ensure jpegs are generated if they need them, perhaps by hooking into the filter late and ensuring jpeg output is enabled. This should also be in the dev note.

[adamsilverstein]

Thanks for the investigation on this ticket. No additional action is required here, so I'm going to close this out. Main takeaway is to ensure dev notes make email client limitations clear.