One of Google PageSpeed Insights’ most common suggestions is to “Serve images in next-gen formats”.
This is also a great opportunity for improving site speed in general.
However, the explanation on why these formats are better isn’t great. Not to mention, there’s no short guide on how to work with them.
And there’s a good reason for that.
Deploying next-gen images formats is complicated. Even Google suggests that WordPress users try a plugin to make their lives easier.
So, if you want to learn more about:
What next-gen formats are and why we should use WebP specifically;
Fixing the “Serve images in next-gen formats” warning (without plugins).
On the other hand, if you just want an easy way to convert and serve WebP images, skip to the end of the article. Not everyone has to be an expert on next-gen images to use them on their website.
Most people are familiar with the classic image formats.
JPEG, GIF and PNG have been widely used for years now. We take them for granted, but the truth is that they all have their downsides.
For example, JPEG images are light, but their quality typically isn’t great. PNGs are high-quality but are also larger in size.
This is the classic tradeoff that all of us make when working with images:
Do we want high-quality images that slow down our website’s load speed?
Or do we want lower-quality visuals in exchange for better site speed?
Truth is, there’s no right answer here. It all depends on the situation.
At the same time, most people don’t have all day to test image formats on their site. They simply want good-quality images that don’t add seconds to their load time.
That’s why the web needs a standard or a go-to image format that combines the best of both worlds. And for a long time, that format was JPEG.
Through the years, people have built upon the older image formats by applying modern compression techniques. As a result, next-gen image formats like JPEG 2000, JPEG XR and WebP emerged.
There’s a long technical explanation of why these formats are better, but the gist of it is this:
They have better compression and quality characteristics.
Using modern formats lets us reduce file size significantly while keeping the same quality. And from these new formats, WebP is the closest to becoming the new default for the web.
First, WebP lossless images are 26% smaller than JPEGs. WebP lossy images are 25-34% smaller than JPEGs with an equivalent quality index.
Second, WebP is developed by Google. Not saying that anything Google touches turns to gold, but you know the search engine will be happy to see you using this format.
Third, WebP can be used for both images and animated images.
Also, other next-gen formats like JPEG 2000 and JPEG XR don’t have nearly enough browser support to be viable. For example, AVIF may beat out WebP in some categories, but it’s still not supported by Firefox, Edge, Chrome on mobile and lots of other browsers.
In short, WebP is your best bet. That’s the format I’ll focus on for the rest of this article.
For a deep dive on the compression techniques that make WebP special, check out this article by Google.
So, if WebP is so much better, why don’t we all use it by default?
Well, the big issue with WebP (and most other trends on the web) is browser compatibility. Not all browsers support the same image formats.
Depending on your user base, WebP images might look good for 80% of your audience. However, the other 20% might get a broken image.
You can find the current state of browser support for WebP here.
Source: caniuse.com. Note that the information from the screenshot can change over time. Always check the website for up-to-date information.
As of January 2022, we’re still waiting on the Internet Explorer for full WebP implementation. Safari's support is also partial, as it's limited to macOS Big Sur 11 and later.
Because support isn’t at 100%, manually serving this format to visitors is much harder than it needs to be.
Put simply, you have to do two things when working with WebP:
Convert your images to WebP (the easier part);
Serve them to visitors (the hard part).
I’ll give an overview of both parts and provide links to detailed guides for step-by-step instructions.
There are probably hundreds of tools online you can use to convert image types.
I’ll go over just a few here, but you can easily find others with a simple Google search.
cwebp command-line tool. If you’re comfortable with command-line tools, this is a good option for simple projects. You can specify whether you want to apply lossy or lossless compression, adjust pixel values, and other options.
Imagemin for WebP. This plugin by npm is a better choice if you’re using build tools or build scripts. Again, you can choose between compression types, sharpness, quality settings, and lots of other options.
Squoosh. Google built this app a few years back. It lets you compress, resize and adjust quality. Most importantly, it has a slider you can use to compare the image in different formats.
Finally, if you edit and export images with Photoshop, get the WebPShop plugin.
Again, converting images to WebP is straightforward. Just pick a tool you’re comfortable with and experiment with different options.
Now for the trickier part.
In essence, this second step consists of two parts:
Serving WebP images to visitors whose browsers support the format;
Keeping the original image as a backup and serving it in all other cases.
Before we begin, note that this isn't a complete walkthrough. I’m just covering the different options with a few examples.
If you want a detailed guide on creating and serving WebP images using cwebp, check out this tutorial by Digital Ocean. It covers the whole process step by step.
The most common way to serve WebP images with a backup is through the HTML markup.
Specifically, we can use the picture tag in combination with the img tag.
Here’s a quick example:
Let’s say we have a JPEG image on our site. Once converted to WebP, we can serve the new version, with the old JPEG as a backup through the picture tag. Here’s how:
Each tag and its order is necessary to get the desired effect.
The picture tag acts as a wrapper for an img tag and an optional source tag;
Browsers that support the picture tag start going through tags, choosing the first resource in a format they support;
Browsers that don’t support picture tags simply skip them. As a result, they only see the img tag. That’s why we always include the img tag as the final element inside the picture.
This is a relatively simple way to serve WebP images, but it's not the most scalable.
Another option is to control WebP serving through the .htaccess file.
Again, the idea is to automatically detect compatibility and serve WebP or another image.
You can create a new .htaccess file and merge it with your existing one. Refer to Step 6 of Digital Ocean’s tutorial - using Apache’s mod_rewrite to serve WebP images for more details.
You can also add a snippet to your website’s .htaccess file that detects browser WebP compatibility. Check out this example snippet by Vincent Orbak if you’re interested in trying this method.
But be warned:
Even he says that “a more responsible way is to just use the picture element”.
As a rule of thumb, messing around with the .htaccess file is not the right option, especially for non-technical users. Rewriting the file can severely damage your site if you don’t know what you’re doing.
Content negotiation is another way to serve different versions of a resource (e.g., WebP or JPEG), depending on the user’s specifications.
In the context of image formats, web clients can use the Accept header when requesting a resource.
This header indicates which content formats they’re willing to accept. Here’s an example of the Accept header in action:
As you can see, the header clearly states that the browser will accept WebP images.
Different variations of this header are also commonly used to specify accepted languages and encoding mechanisms (gzip, brotli).
A few years back, there were concerns about adding more header bytes on the wire with this method. But with HTTP/2.0 having header compression, the overhead is significantly reduced.
This method also has a long history of potential issues with some browsers. If you want more details, I recommend checking out:
This article by Ilya Grigorik for a deeper dive into the history of deploying next-gen images;
This list of the current default Accept values for each browser.
Modernizr is a popular library for the job. It acts as a series of tests that detect which native CSS3 and HTML5 features are available. It lets you take advantage of modern features without leaving users on older browsers with a broken site.
As you can see, serving WebP images isn’t that easy. Lots of things can go wrong, especially on your first attempt.
That’s why you should test the results of your work with a tool like Smartbear’s CrossBrowserTesting. Their “Screenshots” feature lets you easily see how everything looks on different browsers and devices. Plus, it's really easy to use and part of their free plan.
Other tools (like Browserstack) can also help you get the job done. The important thing is to make this check as easy as possible.
Of course, you can also test by hand, but it takes more time and gets annoying after a while.
Now, if you want to avoid the hassle of converting and serving WebP images manually, check out NitroPack.
Our service automatically converts images to WebP. It also keeps the original image as a backup and serves it when browsers don’t support WebP.
The best part is that all of this happens behind the scenes. You don’t need to spend any time or effort on configurations.
Of course, you can adjust image quality from the “Images" settings:
And this is just one part of our image optimization stack. NitroPack also comes with:
Preemptive Image Sizing, which solves the problem of missing width and height attributes without adding them;
Adaptive Images Sizing (in beta), which makes sure images fit their containers perfectly;
Advanced Image Lazy Loading. NitroPack automatically lazy loads all images, including background ones, even those defined in CSS files. On top of that, our service detects declarations in external files multiple levels down an import chain.
NitroPack also comes with everything else you need for a fast website.
If you’re interested, check out NitroPack for:
Of course, we can’t talk about our service without being at least a bit biased. That’s why we have a Free Plan (no credit/debit card required) for websites with up to 5000 monthly pageviews. You can easily test NitroPack out and see the results for yourself.
Evgeni writes about site speed and makes sure everything we publish is awesome.