5

It seems there are two ways to show WebP images to browsers that support it.

  1. Use the HTML Picture element
<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg">
</picture>
  1. Detect on the HTTP server. So request /image and the server detects through the http request headers if the client supports webp or not, if it does serve the webp image, if it doesn't serve the jpg image.

Which approach is better, what are the pros and cons of each?

holydragon
  • 6,158
  • 6
  • 39
  • 62
AndrewHarvey
  • 2,867
  • 11
  • 21

3 Answers3

2

Update Answer (based on comments to the answer):

All-in-all, both approaches would yield similar performance benefits. Which of the two is better depends on your situation (detailed below):

  1. Approach #1 (<picture> tag)

The benefit of using <picture> tag approach is that no change on server side is needed. So, in setups where changing server / CDN configuration is an issue - this should do the trick.

The issue with this approach is it's need of updating existing code. So, for sites with a lot of existing pages - this can be cumbersome.

  1. Approach #2 (Change image format delivered based on http headers)

The major benefit of this approach is no code change within your HTML.

One thing to be careful about with this approach is - you'll have to be sure your server environment and CDN support delivering different image formats based on HTTP header.

Performance wise - there is no difference between the two approaches. The additional CPU consumed on the server side to detect the header and respond accordingly is generally minimal.

For more details, check out https://www.tezify.com/how-to/using_webp_images/

Original Answer:

Approach #1 (using element) makes better sense. Primarily because as browser's support for webp will improve, the newer browsers will download webp images.

In case of approach #2 (using server side detection via user-agent-string), you'll either have to update the detection code OR improved webp support will not reflect in your image loading solution.

Punit S
  • 3,079
  • 1
  • 21
  • 26
  • 1
    Approach #2 is not using the user agent at all, it's based on the Accept header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept – AndrewHarvey Nov 29 '18 at 20:18
  • Got it, in that case the issue I stated with #2 doesn't exist. For #2, will the server serve a different HTML (one with webp images in IMG SRC) if webp is accepted? – Punit S Nov 30 '18 at 06:28
  • The idea was to put a url like /image/1 in the src, and get the web server to serve either webp or jpg based on the Accept header. So the HTML is the same for everyone. This way if someone chooses to right click an image and copy the URL and then share it, the receiver won't ever get a link to a format they can't open,which I think is a downside ofb#1. The downside of #2 is you probably can't do this with S3 etc, but through your own webserver config you can. – AndrewHarvey Nov 30 '18 at 10:38
  • Also, if you are leveraging a CDN, the /image/1 approach may not work. So - your image requests will have to be always served by the web server. – Punit S Nov 30 '18 at 12:21
1

HTML5 <picture> solution or JavaScript soulution Detecting WebP support is better because fetching website is faster (less requests). JavaScript solution is possibly the best solution considering the fact for performance reasons frameworks like React or Vue populate dynamic fragments of website via JS and HTML is only "page skeleton" what allows all resources to be cached for even better performance (so only API has to be downloaded and updated). Bad side of HTML solution is <picture> in an older browser can be displayed not as expected. You may also find this article helpful.

Zydnar
  • 1,472
  • 18
  • 27
  • 1
    I don't understand how it's less requests using over Accept header to determine support https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values – AndrewHarvey Nov 17 '18 at 04:34
  • @AndrewHarvey It depends on the architecture, but it's faster anyway because server don't have to compile templates or choose between compiled views. – Zydnar Nov 17 '18 at 13:00
  • 2
    There's no compiling templates, it's just the web server picking which image format to serve. – AndrewHarvey Nov 17 '18 at 23:06
1

I'd say if it makes sense for your application, it's better to detect it server side by examining the 'Accept' header, as it is doesn't depend on the support for the <picture> tag, which can be consulted here. Most modern browsers support it, but older versions don't.

The reason I can think of for doing it client side is because its a static app or you have no control over the server.

learn2day
  • 1,566
  • 1
  • 14
  • 17