A simple way to deliver alternative image formats - and why you shouldn’t be using it!

For what seems like an eternity, we’ve been restricted to just a handful of image formats on the web. Today, for the most part it’s still JPEGs for photos, PNGs for logos and graphics, and GIFs for simple animations. In other words, nothing very different from what we had ten years ago. There are SVGs too, of course, which are great for simple graphics that scale automatically with the viewport. But in this post, the focus is on bitmap images, where different colours are mapped to a fixed number of pixels.

Alternative formats

Other bitmap formats are available. Microsoft’s JPEG XR has been supported in Internet Explorer since 2011. Similarly, Chrome has supported Google’s WEBP format since 2012.

Both can deliver better compression than their JPEG and PNG rivals. They also support transparency, which is a huge benefit for photographic images that require it. This is because the only other option is a 24-bit PNG, which can mean very large file sizes.

Chrome’s early adoption of the responsive images specification may have allowed Google’s WEBP format to steal a march on Microsoft’s JPEG XR. Since Internet Explorer has never supported the <picture> element (it’s first supported in Edge, version 13), there hasn’t been much point using the responsive images spec to deliver JPEG XR images.

So at least some of the time, you’ll find that you can get a smaller, faster loading file if you use something like WEBP instead of JPEG or PNG.

Responsive images spec to the rescue?

If you want to selectively deliver new formats to supporting browsers, your best bet is probably a server-side solution to detect the user agent and direct requests accordingly.

If this isn’t an option, you should now be able to achieve the same result with a few lines of HTML, thanks to the responsive images specification.

In a previous post, we looked at using the spec to deliver the right image for the viewport.

Well, you can also use it to deliver a WEBP image (for example) to supporting browsers, with a fallback to a JPEG for browsers that don’t support WEBP or that don’t support the spec.

Here’s a simple example:

<picture>
<source srcset="hero-large.webp" type="image/webp">
<img src="hero-large.jpg" alt="">
</picture>

This is great – the spec is supported in all major browsers, except Internet Explorer, which will fall back to the JPEG (and doesn’t support WEBP anyway).

Except for the bug.

Redundant downloads in Safari

In Safari, the above example will work – unless you have a script at the top of the page.

If you do have a script reference, the browser preloader will come into play and load the WEBP image in advance, even though it can’t do anything with it (as WEBP is not supported in Safari).

The end result can be that the JPEG fallback, which the browser does need, is actually delayed.

This is illustrated in the waterfall chart below (tested using an iPad with iOS11 on a public instance of WebPagetest):

Credit (and thanks) to Andy Davies and Paul Calvano for finding this, as well as to Colin Bendell and Tim Kadlec for identifying the root cause.

Hopefully, the bug will be fixed soon, at which point I’ll go on to cover how you can combine delivering alternative formats with displaying the right image for the viewport.

Published date:  30 November 2017

Written by:  Alex Painter

comments powered by Disqus

Filter By Service

Filter By Date