image/webp header not recognized by page speed insights

[RealMutant]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://theaegisalliance.com/2023/02/25/michigan-man-wrongly-convicted-freed-after-21-years-in-prison-when-serial-killer-is-linked-to-murders/

What happened?

​This is from a support ticket with LiteSpeed Cache, a caching plugin for WordPress. Page Speed Insights accepts the image header */* but not image/webp. It's causing PSI to not recognize the webp images but instead view them as jpg. The image extensions are jpg.webp

This wasn't an issue until sometime last year, and may have to do with when PSI had a revamp where it displays more webpage data aspects. The webpage I've included is just one example, but this affects the featured image of posts on the entire website. PSI may recognize the image/webp format sometimes, periodically, or when first testing a link, but most of the time it doesn't.

the PSI is using following request header

​02/26/23 15:43:38.688 [66.249.93.133:41396 1 XWc] User Agent: Mozilla/5.0 (Linux; Android 7.0; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4590.2 Mobile Safari/537.36 Chrome-Lighthouse
02/26/23 15:43:38.688 [66.249.93.133:41396 1 XWc] Accept: */*​

from the plugin's code, we added

​RewriteCond %{HTTP_ACCEPT} "image/webp";​

​as condition check , to check if browser supports webp or not
but you can see the Google only sends the request with Accept: */* , it does not explicity indicate it accepts image/webp format , so webp replacement did not take effect
while on any of real browser , like this

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7

where it explicity included image/webp in its header , so plugin proceeds with webp file

What did you expect?

I was expecting PSI to recognize the webp images as it did before the revamp.

What have you tried?

I've tried removing functions.php code for faster LCP load times. I've also tried different functions.php code for faster LCP load times. Neither way made a difference for recognizing webp images, so the issue is with PSI.

How were you running Lighthouse?

PageSpeed Insights

Lighthouse Version

10.0.1

Chrome Version

110.0.5481.177

Node Version

No response

OS

Windows

Relevant log output

N/A

[adamraine]

It looks like the page is serving the jpg version of the image for PSI:

On PSI the image URL is:
https://theaegisalliance.com/wp-content/uploads/Michigan-man-wrongly-convicted-freed-after-21-years-in-prison-when-serial-killer-is-linked-to-murders-1024x538.jpg

When loading normally:
https://theaegisalliance.com/wp-content/uploads/Michigan-man-wrongly-convicted-freed-after-21-years-in-prison-when-serial-killer-is-linked-to-murders-1068x561.jpg.webp

[RealMutant]

My apologies for the confusion, this issue may be with the LiteSpeed Cache plugin that hasn't been updated to include that Internet Explorer is now defunct. A user in the Google Developer community made this point, and it's the recommended answer I chose in my post,

"I would add that the plugin's logic is perhaps wrong here. */* is the client saying it will accept any mimetype, so strictly speaking, it shouldn't have to explicitly look for image/webp

The reasons browsers send them really is more about using the quality values, the q part, to denote the priority they want the content in, so

text/html,application/xhtml+xml,application/xml;q=0.9 = 0.9, the highest priority for these types

image/webp,image/apng,*/*;q=0.8 images and everything else, a little lower (the inclusion is perhaps more legacy for servers that don't know webp is specifically an image.)

I'd say with the demise of IE 11, realistically nearly every visit is going to be from a browser that supports webp, but I guess a plugin for a webserver might not be able to cut off support?

FYI, googlebot also crawls with the accept header of */*"

[adamraine]

I see, the PSI request header is different from what a normal browser would send. When I looked at the PSI request headers, the header for Accept was missing so maybe Chrome is using a different default in each scenario?