Site accelerator damaging transparent background of WEBP images

Hi there,

It looks like the issue is coming from the MonsterInsights plugin. As I’m deactivating this plugin the issue is resolved. You can check here: https://d.pr/i/Ps02vs

You may contact them to check why the issue is there when activating the MonsterInsights plugin because it is an analytics plugin and shouldn’t affect WebP images. They may be able to find if there is something they change recently.

One more thing I want to point is Jetpack doesn’t actually require that you upload and store WebP images on your server. Instead, it detects when a site visitor browses your site using a browser version that supports WebP and serves them images that have been optimized to use the WebP format.

• https://jetpack.com/support/site-accelerator/#how-site-acceleration-works

Thanks for the reply, Aminesh, but I am afraid my testing and yours don’t agree.

First, I understand that nothing requires me to use WEBP formatted images. In this case I compared the sizes of certain image files and found that WEBP format is substantially smaller than PNG or JPG, so I chose to use that format in an attempt to make things smaller (and thus load faster). it was my choice. Nothing was required or even influenced by JetPack. Nearly all browsers support WEBP at this point – see https://caniuse.com/webp – so I am using it.

Second, I just tested a similar page on our staging site with MonsterInsights deactivated. Here is the link: https://stage1.blueridgeca.org/cache-testing-page/

I started with Site Accelerator turned off, Lazy Loading turned off, and MonsterInsights completely deactivated. When served that way, the page looks fine.

I then turned on Lazy Loading and the page continued to be fine.

I turned on Site Accelerator | Speed Up Image Load Times (but not Speed Up Static File Load Times) and reloaded the page (shift-reload in Firefox). This time the WEBP version has a black background.

In all of the above tests MonsterInsights was deactivated.

I left the staging site in that configuration, so the link above will work for a while. At least until we reload staging from production again.

Given this result I am certain that MonsterInsights has nothing to do with this error. I can’t address what you saw, but I am sure that the issue is not related to that plugin on our server.

Also, the JetPack page about Acceleration can only be described as confusing. Near the top I see this:

Browsers that support the WebP image format will be served WebP image data (note that the file extension won’t change).

but farther down I see this:

We only fetch, resize, and serve GIF, PNG, and JPG images from servers that listen on port 80 for HTTP and port 443 for HTTPS. This applies to about 99.99% of the web servers in the world. If you are having issues, please try using the jetpack_photon_reject_https filter.

So which is it? Does JetPack accelerate WEBP images or does it not do so? My testing clearly indicates that it tries to do so and breaks them in the process if they happen to have transparent backgrounds, which is clearly the case for us.

I fixed this issue on our production server by adding a white background to the images in WEBP format and uploading them to our WordPress media archive with new names, then replacing the images in the pages in question with those new ones. But that is not a great solution, and it should not be required. JetPack is clearly damaging the background when serving WEBP format files if they happen to contain transparency. That’s not good.

Sorry for the confusion on this.

There was a recent change to Site Accelerator in which we do attempt to optimize WEBP images. I was able to reproduce the error that you experienced and have reported the issue to our development team.

At this time, I would suggest that you disable Site Accelerator while we look into this.

Thanks for the clarification on this, Bob. Much appreciated.

At the moment I have a workaround in place, and it will do. And I will keep an eye on these things in the future.

I’ll pull down the demonstration pages linked above since you have reproduced the error and don’t need my example anymore.

I am tempted to mark this as resolved, but I will leave it for now as I’d like to hear when the fix is pushed live, if that can be arranged.

Yes, we’ll let you know here when we have an update on this issue. Thanks.

Hi @jrpstonecarver –

We have deployed some changes to the Site Accelerator code that should resolve your issue. Could you try again and confirm that it works?

Hi Bob. A quick test indicates the problem is resolved.

I will close this as resolved and should the problem recur or only show us as something more complicated I will open a new thread (or whatever these things are called).

Thanks for the quick response on this.