DEV Community

loading...
Cover image for Speed up your web page loading with WebP

Speed up your web page loading with WebP

Khalyomede
Fullstack developer @ Carlili
Updated on ・3 min read

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:

WebP versus JPEG image format

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.

Original image

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>
Enter fullscreen mode Exit fullscreen mode

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"));
});
Enter fullscreen mode Exit fullscreen mode

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!

Cover photo by Pixabay from Pexels

Discussion (7)

Collapse
martyonthefly profile image
Sylvain Marty

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...

Collapse
isfotis profile image
Fotis Papadogeorgopoulos

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 with source being 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?)

Collapse
khalyomede profile image
Khalyomede Author

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 :)

Thread Thread
isfotis profile image
Fotis Papadogeorgopoulos

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 picture like a generic div). 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, and picture is 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 :)

Collapse
khalyomede profile image
Khalyomede Author

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...

Collapse
abhishekcghosh profile image
Abhishek Ghosh • Edited

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 :(

Collapse
khalyomede profile image
Khalyomede Author

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.