it’s not really a bug , from code aspect, everything is working as desired , in human word/logic , it’s like:
- if browser sends request with header
accept: .... image/webp
to explicitly state it supports webp
- then plugin will try to use the webp file whenever possible
- on the other side , if browser doesn’t state
accept: ... image/webp
, it may or may NOT support webp , to be on the safe side , plugin will then , not , use the webp file , just in case , serving bigger size image is still better serving un-renderable image to browser
the thing is FF now seems doesn’t send header with image/webp
now , I remember it used to do that , like Chrome , you can see something like accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
that clearly state image/webp
in request header
<IfModule LiteSpeed>
RewriteCond %{HTTP_ACCEPT} "image/webp"
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.*).(jpg|jpeg|png|gif) $1.$2.webp [T=image/webp,L]
</IfModule>
you can try this , it will forcefully load the webp file if exists and browser supports , but CF will also cache the jpg URI with webp content which may end up in error for browser that doesn’t support webp
but nowadays the chance for a browser not having webp is quite small though.