Images are widely used
Images take more and more space in our bandwidth.
W3Techs statistic shows that 90% of all websites uses images.
For news.google.com, images count for 44 % of the assets loaded on the home page, taking 30% of the load time (source: I manually analyzed the page using DevTools).
Webp
Google proposed the WebP picture format, which provides smaller image size.
According to a case study conducted by Google themselves on different lossless compression algorithm vs webp, this last has shown up to 42% of saved bytes compared to the classic png compression library.
I have also tested against a JPEG image (1920x1080) and here is what it gives:
As you can see, the JPEG image weights 530KB versus 195KB for the WebP image, which is 36% less heavy, not far from what Google states against PNG.
Coverage
WebP is correctly supported across all the most popular browser (75% coverage at the moment).
| Browser | Supported | Minimum version | Release date |
|---|---|---|---|
| Internet Explorer | ✘ | ||
| Edge | ✔ | 18 | Nov 13, 2018 |
| Chrome | ✔ | 71 | Dec 05, 2018 |
| Firefox | ✔ | 65 | Jan 29, 2019 |
| Opera | ✔ | 56 | Sep 25, 2018 |
| Safari | ✘ |
source: https://caniuse.com/#feat=webp
Using WebP in production
Here is an example of optimization for web pages using <picture> HTML tag:
<!-- before -->
<img src="/img/mountain.jpg" alt="Moutains view" />
<!-- after -->
<picture>
<source type="image/webp" srcset="/img/mountain.webp" />
<img src="/img/mountain.jpg" alt="Mountains view" />
</picture>
In case WebP is not supported by the user agent, the browser will fall back to the <img />. Picture is an HTML tag with 87% of coverage (merci Sylvain for improving this part), so if the browser does not support the <picture> tag, it still fallback to the <img /> tag anyway (thank you Fotis for the info!).
The <picture> tag is so much more powerful, it can let you choose an image size depending the current browser viewport width for example. Learn more on the MDN page.
Tools for turning images into WebP format
There is plenty of services online to convert images to WebP. I personally automatize this task with Gulp.js.
const gulp = require("gulp");
const webp = require("gulp-webp");
gulp.task("webp", function() {
return gulp.src("src/img/**/*.{jpg,jpeg,png,svg}")
.pipe(webp())
.pipe(gulp.dest("dist/img"));
});
To go further
Let me recommand you this incredibly complete image optimization article by Boris.
Conslusion
Building or maintaining a website also comes with responsibilities towards our users: we should also consider the users on a light data plan.
I think web development is offering so much possibilites in term of optimizations. This is the perfect opportunity to improve engagement by reducing the user bandwidth usage, and in the same reducing your server i/o time.
That is why I think WebP might be a good ally when it comes to trimming those precious bytes without compromising the user experience.
Happy optimizations!
Top comments (7)
Thanks for this post, its very interesting.
Nethertheless, I think its hard to say that 71% coverage is good enought because, to be sure this will works, we also need to cross this with the support of the
<picture>element which is 81% coverage.I know I'm too sceptical here but I'm mostly desperate to see how slow are browsers to implement W3C living standards...
The reason the
<picture>syntax is structured that way is to enable progressive enhancement. If a browser does not understand how to handle<picture>, then the<img>inside is shown instead. Same withsourcebeing forward-looking for unknown formats, as the article mentions. So the fallback WebP -> Jpeg -> img with src is pretty clean ime. Nothing bad happens either way!Evergreen browsers have been quite responsive to supporting
<picture>for a few years now too :)(The caniuse link gives me 87% percent, could it be a font issue or the "site data" setting being on?)
Gonna double check for caniuse filters, I tell you that right after I checked.
I did not know the browser will fallback to the img tag if the picture tag is not supported. Thank you so much for sharing.
I guess I will still mention the picture tag coverage to be clearer :)
Ah, I meant the coverage percentage for picture, which caniuse puts at 87% and I thought the comment above said 81%.
I think if you mention the picture tag coverage, it is best to also include that it will fall back to the img tag (basically treating
picturelike a genericdiv). It is a common misconception that I see about using features, that we might avoid using them if they are not supported everywhere. In reality, they are often designed to progressively offer a better experience where supported, andpictureis there in all evergreen browsers.Mat Marquis, one of the people who worked on the spec back when it was established, goes over some of the history and progressive-enhancement decisions. The best I remember is in the ebook Image Performance, from A Book Apart. I'll see if I can find some other reference, it's a great read :)
Very well noticed! I completely not took into account the picture tag, which make this part irrelevant. Gonna rectify it thank you :)
Same feeling as you, I am very sad to see the slowness of LS in browsers...
Thanks for the nice article, and I love webp, but there's a fundamental point that we're missing here. WebP shaves off bytes at the cost of more computational demand. For users where the bottleneck is network bandwidth, this can do great. But for users especially on mid to low range mobile phones, the cpu is the bottleneck a lot of times and webp actually may perform worse than png or jpegs. This is something you might be interested to understand better - who are your users, and are they really benefitting from webp out there in the wild? The sad truth as it is, nothing in this world is for free :(
Awesome input Abhishek, thank you! I am understanding better the reason why webp is performing better in the bandwidth, I will definitively dig this and improve this article.