We aim for WebP generation and delivery to be automatic; however, in certain situations WebP delivery may have a conflict.

The first step is to right click on the image, hit save and see if the file actually is WebP as with our URL structure, it may appear to be .png by conventional naming, but the extension you see is for the ORIGINAL file via the CDN

For example: https://wpcompresscomfa428.zapwp.com/q:intelligent/retina:false/webp:true/w:1440/url:https://wpcompress.com/wp-content/uploads/2019/10/browser-bigger.png would actually be a WebP when possible as webp:true is set, even though the original file ends in PNG.

The most common issues surrounding WebP delivery are:

Viewing the image from a non-fully supported Browser such as Internet Explorer or Safari
The image is located within CSS, in which it's actually FASTER to serve the original format then to use CPU to dynamically rewrite to WebP (the potential savings are not worth the processing delays)
The image is an unsupported format for conversion such as .svg or .gif
You have extremely agressive server side caching or plugin caching that saves the initial device profile and sends it to all future visitors.

Whenever possible, we will serve the WebP image, if you need help determining which issue you're facing we're happy to do so - but these are the most common examples of why WebP can be disrupted.
Was this article helpful?
Thank you!