lighthouse icon indicating copy to clipboard operation
lighthouse copied to clipboard

Disable WebP warning when Cloudflare Polish says WebP is bigger

Open gijo-varghese opened this issue 3 years ago • 4 comments

Feature request summary Cloudflare Polish convert images to WebP from its CDN. However, if Cloudflare finds that converting to WebP results in higher size, it will deliver the original image instead. Lighthouse still gives the warning to serve these images as WebP (next-gen format).

Cloudflare provides a response header cf-polished: origSize=70188, status=webp_bigger.

file-prLn9XAfLT

What is the motivation or use case for changing this? Many customers believe either Polish is not working or converting to WebP will increase the site's speed even more when analyzed with Lighthouse.

How is this beneficial to Lighthouse? Not every image, when converted to WebP, will result in a smaller size; sometimes, it will be higher. It would be great if Lighthouse could check these headers and remove that warning if webp_bigger.

gijo-varghese avatar Aug 07 '22 03:08 gijo-varghese

Polish generates webp on the fly, it's webp but it weighs more than webp created with more effort (parameter) We have been moving this image generation to our servers instead of using polish, workers or image resize api and went from 1.4TB/day to 1.1TB/day (now less because we build mobile and desktop variants for the same URL based on headers and reduced like 60%)

jorgellose avatar Sep 06 '22 17:09 jorgellose

+1 for this issue report and I agree 100% with @gijo-varghese. The Lighthouse team should definitely look into the response headers like these and count that in the report generation process.

isaumya avatar Sep 07 '22 11:09 isaumya

It's perhaps not particularly helpful feedback for Cloudflare users who agree this change would be helpful, but personally I do not want to see vendor specific solutions submitted to inform LH audits.

Consciously or subconsciously, the inclusion of a specific vendor in Lighthouse code gives weight their products. In the case of Cloudflare (and their many documented poor choices of hosting fascist, abusive and dangerous content), I think it's more important than ever to not uplift their products.

Taking a step back, adding support for a vendor-specific, non-standard HTTP header should be avoided at all costs.

benschwarz avatar Sep 08 '22 01:09 benschwarz

Hi @benschwarz, I do get your point but do not quite agree with it. Though this particular issue has been opened in for the cloudflare specific response header, but it's not 100% specific to Cloudflare. You see there are many image optimization platforms out there like Optimole, cloudinary, imagekit.io and many more who does the same thing. I mean any cloud image optimization platform when it will see that webp is bigger then it will serve the normal version.

I think the goal of this issue should be to focus on creating a system where users can give feedback about other image optimization platforms as well and what response header they add in this situation, so Lighthouse should not only consider the Cloudflare case but all other image optimization platform cases as well.

isaumya avatar Sep 08 '22 10:09 isaumya

We don't want to defer to a response header from CF to be the source of truth on potential savings. But we don't want our guidance to conflict.

Our audit is based on savings from webp AND avif so avif should be attempted here. (By CF in this case). We feel confident that we're only showing this suggestion when there's at least 8k of savings available in one of these formats. (at 75% quality).

paulirish avatar Jan 24 '23 20:01 paulirish

I agree with @jorgellose, we have several examples where CF returned status=webp_bigger but when attempting to convert to WebP ourselves, we actually saved 40-50% with no losses. Also, as mentioned by @paulirish, AVIF could potentially help save even more. Unfortunately, if you use CF, the AVIF format is only supported by CF Image Resize for now, not yet in CF Polish.

Bruno-Meowtel avatar Feb 22 '23 22:02 Bruno-Meowtel