webp browser support is far less than popular statistics suggest

[jkon]

Recently I started to rewrite the core of a web app in Java (not including the Admin part). I have discussed ideas with colleagues and friends and one thing that seemed to be an agreement was that it is time to stop keeping the same image in two formats jpg or png or gif and in webp format. Not for this , but for other browser features like SharedWorkers support , WebSockets support e.t.c. I decided six months ago to put a tracker client side reporting back server side all this various technologies that the actual browser support , in some of our apps with rather heavy traffic . So I added the webp support expecting that the percentage of clients that don't support it is really low as the statics of the popular "can I use " suggest.

But the results are really weird to me , it seems between 7% and 15% of clients, depending on the app's audience, don't support WebP. In almost all of these cases, both client-side and server-side detection methods agree. It seems that the majority of them are in mobile in WebView or a similar technology.

I am writing about this because I found it extremely weird that something like this is happening but it is not reported (in my knowledge at least). I'm curious if anyone else has encountered similar issues or has real life data to confirm or refute this finding.

[rproffitt]

Read https://developers.google.com/speed/webp/faq and it seems a stretch that 7 to 15% of visitors to a web page don't support this.

Maybe someone has a phone with Android 4.0 but how far back in time do you really need to reach?

[jkon]

Hello rproffitt,

Read https://developers.google.com/speed/webp/faq and it seems a stretch that 7 to 15% of visitors to a web page don't support this.

I know that Google keep saying that you must still have a fall back mechanism to legacy image formats , but I thought we were finally ready to exclusively use WebP images after so many years. Let's say that an eShop has 250000 products , each product has 3 to 10 images and you keep them in just three size families. Keeping the webp version and the legacy format version in all of those images is something that you would want to avoid. Also it adds a complexity level (choosing between the webp version and the legacy format version) in each image that you want to avoid. But apparently we are not there yet and we must still in new web apps keep both formats

Maybe someone has a phone with Android 4.0 but how far back in time do you really need to reach?

I'll use statistics from a web app that is in the lower limit of webp browser support in its visitors in the last month. 17.5% of its visitors' clients don't support WebP format. Of those, 99.5% are on Apple devices (iPhone:86.2% and Mac Os:13.3%) based on the agent that is reported in the request. I knew that Apple had its issues with the webp format (started by Google) but it supposed that after the IOS 14 it should be supported. Again apparently , they don't. Interestingly enough , at the same period at the same app some iPhone and more Mac reported agents of the clients supported webp but they are the minority of web traffic from Apple devices.

I detect if a client supports webp format both server side and client side (both of those detection techniques agree more than 99.9%) .

• Server side if the "accept" in the request headers in lower case contains "webp"

• Client side with the known js function:

  function supportsWebp()
  {
  var elem = document.createElement('canvas');
  if (!!(elem.getContext && elem.getContext('2d')))
  {
  return elem.toDataURL('image/webp').indexOf('data:image/webp') == 0;
  }
  else
  {
  return false;
  }
  }

Some of this is likely due to mobile users using browsers embedded within apps (WebView or other similar technologies) because some referrers of those are from Facebook. Facebook mobile app in iPhone is using its own custom in-app browser. I know from the past that embedded browsers in a mobile app (with WebView or custom in-app) have have inconsistent support for features (I could provide more examples if anyone wants that don't have to do only with webp) and even alter the "user-agent" header (making the statistics I have rather shaky). So this is a part of the problem with the discrepancy of popular "can i use" statistics and real life ones , but still it is a small part of the issue.

One might assume that all Apple devices in this app that don't support WebP are running iOS versions older than 14. However, this isn't the case (how could it be , by the way). Here are some stats from the clients that don't support webp (100% are all the clients that don't support webp) in this app the last month using the first parenthesis in "user-agent" header (I include only the 10 most popular of them):

24.67% iPhone; CPU iPhone OS 17_6_1 like Mac OS X
12.86% iPhone; CPU iPhone OS 17_6 like Mac OS X
11.76% iPhone; CPU iPhone OS 18_0_1 like Mac OS X
10.25% Macintosh; Intel Mac OS X 10_15_7
07.21% iPhone; CPU iPhone OS 18_0 like Mac OS X
06.90% iPhone; CPU iPhone OS 18_1 like Mac OS X
03.16% iPhone; CPU iPhone OS 17_7 like Mac OS X
02.97% iPhone; CPU iPhone OS 17_5_1 like Mac OS X
01.74% iPhone; CPU iPhone OS 16_7_10 like Mac OS X
01.51% iPhone; CPU iPhone OS 17_5 like Mac OS X

As you can see all of the above are IOS > 14 that supposedly supports webp and in one case macOS Catalina version 10.15.7 that again supposedly supports webp format.
One might think that it could have something to do with the browser webkit version , but in 99.48% of all the cases that don't support webp format in this app the last month I get "AppleWebKit/605.1.15" in the "user-agent" header that supposedly supports webp format.

I have written about this at such length because if anyone would be informed only from the common statistics and not gather real life data might conclude that it is time to drop legacy image formats support and keep images only in webp format. Probably the "webp is widely adopted these days in all modern browsers" is just one more programming myth that many believe without testing it.

I keep a small reservation in case those clients report that they don't support webp format but in reality they do (that I can't see how this could be done , and why).
Additional insights or observations on this topic are highly welcomed.

[rproffitt]

If I were to make a bet, there's something else going on. Take for example the usual pop-up and other blockers.

1. To decipher what it is this time, you'll need a iPhone that fails to debug with.
2. https://caniuse.com/?search=webp seems to, at first say no problem. HOWEVER, scroll down to "HTMLCanvasElement API: toBlob: type parameter supports "image/webp"" and it all falls apart.

[jkon]

Hello rproffitt , you made an interesting point. Although those clients report both server side and client side that don't support webp image format , there is a chance that 1. they don't have correct the "user-agent" in their request header so the server side detection fails and 2. at the same time in client side , the JavaScript method that I use to detect if webp is supported fails although webp is really supported.

All the iPhones that I have access to , report that support webp image format both server side and client side detection. So I have a bit of a problem testing this one.

But I will create one additional test in client side in this specific app , I will use the JavaScript code that Google has at https://developers.google.com/speed/webp/faq to detect client side the webp features that the browser supports (lossy , lossless , e.t.c) and then send it to server side to be saved in a table. If one of those return true (especially the lossy) then it could mean that they really support webp but for some reason their "user-agent" header don't includes it , and I will try to make a rule from there for server side detection as well.

I will keep you informed with the results of this test

[toneewa]

The global share of Safari is ~18.07%. Sounds about right to me.
Remember, web servers really don't care what a user-agent string is. They just check for a word. E.g., try to access a webage that doesn't want you to browse it without a particular user-agent - it halts, and displays the 5 major browsers to download.

This reminds me of the time I designed a website for a tv actress. It used Adobe Flash. They liked it, but wanted it to work on Macs. The whole thing fell through, after I stated the odds of someone using a Mac were really low (at the time).

If your goal is too serve everyone, include it, otherwise, tell the user what is expected for the app to operate or what is supported/unsupported.

[ellasophia]

I’ve noticed that WebP browser support isn’t as widespread as some stats claim! Sure, many major browsers support it, but there are still issues with older versions or some less common browsers that just don’t render it well. It’s frustrating because WebP offers such great compression for images. Hopefully, more universal support comes soon, but for now, it’s important to keep in mind that fallback options might still be necessary for some users. Anyone else run into issues with WebP compatibility?

[jkon]

Hello, I created three additional tests to check if the browser truly supports the WebP image format. One test used the Google code we discussed earlier, another tried to load a very small WebP file and then checked its width, and the final test had the WebP image directly into the HTML code and checked its width.

Since we're only talking about one app and this test has been running for nearly two days, I don't expect the results to be entirely accurate, but I believe they are indicative.

I filtered out requests from bots. The results from these were all over the place, and the one robot we truly care about (!) supports WebP, so there's no point in investigating those further.

Approximately 0.05% (one client in every 2000 requests) are from older agents that don't support WebP, such as older Firefox or Safari.

Approximately 0.2% (two clients in every 1000 requests) are from Apple devices (primarily iPhones, but a few Macs as well) whose user-agent request headers suggest WebP support, but they failed in all five tests. In the two tests where I could capture img.onerror, it seems they failed this way, but the JavaScript img.onerror event doesn't provide any additional insights or error messages. These 0.2% of clients successfully loaded other image formats like PNG or JPG, and their IP addresses didn't reveal anything unusual (likely real visitors). Additionally, their results for other metrics like WebSocket, Shared Workers, and Web Workers support were as expected. One common thing among them was that their visits were limited to one Page View , significantly below the average for this app.

I've tried to dig deeper into this 0.2% but haven't found any further information. So, for now, I'll accept these results. If anyone has any additional explanations, please share.

Given this data, it's time to make a decision. Do we care enough about those 0.25% of visitors, who likely have similar issues on many other websites, to keep every image in two formats and check each time? Or should we stick with a single format and display a message for those affected?

I tend to the first option (only WebP images) mainly because the browser versions of this 0.2% suppose to support WebP image format, but this is something that needs more consideration.

[rproffitt]

As HAL9000 said: "Yes. It's puzzling."

Unless you can grab hold of that iPhone or get deeper detail you won't be tackling this or rather you'll be swatting at clouds. In other words, try something and wonder if you connected.

There are out of your control client side issues you won't be fixing.

1. MDM corporate filters.
2. Parental Controls.
3. Outright transport failures. ISP, Internet packet drops and errors in router firmwares for example.

[gediminas.bukauskas.7]

Pack the application and dependencies into some container. I am using docker, use kubernetes if you hate docker.

[jkon]

Pack the application and dependencies into some container. I am using docker, use kubernetes if you hate docker.

gediminas.bukauskas.7 I don't understand what this has to do with serving (or not serving) legacy image files (jpg, png, gif) both in those formats and in webp , or only in webp. If there is a connection please enlighten me.

Having more data, I can now say that the 0.25% of browsers that report, in various of my tests, that don't support WebP image format really don't support WebP and likely have a valid reason. They are mostly older (pre-2020) iPhones and a few older Firefox browsers as well. The question is if you can ignore this 0.25% (which will keep decreasing, but I don't know how slowly) and serve only the WebP image format. If you've faced this dilemma recently or have any ideas, please share.