Resize Images + Serve As WebP

I recently implemented Webp images on a client site. All seemed to go well (thanks for some support here). We saw improvements on Google Page Insights.

We have just now looked to implement image resizing for some of the images on the homepage.

What we are finding is that as well implement it, those images are no longer being served as Webp, they are going back to their original JPG or PNG.

i.e the code was previously;

<img loading=lazy src="" alt="">

and we changed this as follows to implement resizing;

<img loading=lazy src=",height=220,quality=100/wp-content/uploads/2022/01/JS-Wetpour02-scaled.jpg" alt="">

The resizing feature is working correctly, but its coming down as JPG.

This image was downloading as WEBP, but now google page insights is saying the image is JPG and we are not serving next gen images. Bit of a one-step-forward two steps back scenario.

Does anyone know if image resizing supports also serving WebP images using Polish?

I am afraid this will always be like that until Google changes something in their Lighthouse code so the tool/bot for checking Insights get the webp served while looking for the jpg.

To the end-user/visitor, it’s webp in the web browser, if the web browser supports this image format.

Furthermore, is there a Vary header sent from the origin for that specific JPG images?

From the docs:

Polish may not be applied to origin responses that contain a Vary header. The only accepted Vary header is Vary: Accept-Encoding .

Sometimes, it will be just JPG as it may be optimized enough already and no reason to serve it as a WEBP.

Thank you, but the issue is only with the images that we are implementing using polish. Even in developer tools those images are showing as JPG, whereas the images coming via Cloudflare where we haven’t used resize (just polish) are coming down as WebP correctly.

i.e its only when we resize that Cloudflare doesn’t seem to be pushing them as Webp.

Image resizing will optimize images, and serve WebP when the browser accepts it, provided you request it, by adding format=auto to the URL:

1 Like


I think Lightouse by the code at GitHub still searches for <img> tag and it’s src value? I might be wrong and it’s “byte comparasion audit” of how much could be saved, if so.

Despite of this, even if you add a WEBP image as a value of the src attribute, it might still find some possible savings and recommend this so far (if not used some drastic optimization and reduction of the data from it - lossy vs losless compression?).

    const pageURL = artifacts.URL.finalUrl;
    const images = artifacts.OptimizedImages;
    const imageElements = artifacts.ImageElements;
    /** @type {Map<string, LH.Artifacts.ImageElement>} */
    const imageElementsByURL = new Map();
    imageElements.forEach(img => imageElementsByURL.set(img.src, img));
1 Like

I’m not a developer, though I dirt my fingers by tinkering here and there… but when running the F12 > Lighthouse audit for the OP site, it only suggests NexGen for images that were resized (and are not yet using WebP) and one image kept by Polish as JPG, as the conversion was deemed “not needed”.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.