This article was originally published on this site

Why bother to optimize images? Let me ask you this; when was the last time you saw a website without any images on it? “Never” would be the right answer. 🤷‍♂️ Images are just too essential. And this isn’t even about that cringe-worthy stock photo to go along your “10 online marketing tips” post. Images are useful for multiple purposes. Think layouts, design element, logos, profile pictures and, yes, blog images too.
Frankly, you can’t have a website in 2019 without using at least a handful of images on it. That being said, images are not that straightforward to figure out for a website owner. Even setting aside the challenges of what images to use and where, there are also issues of displaying those images from a purely technical point of view:

  • How to deliver responsive images across multiple devices?
  • How to make them look great on all those devices?
  • And, most importantly, how to make sure they load in decent time?

These are the questions we’re answering today. Here’s your ultimate guide on how to optimize images for your website and make them look great on all devices:

How to Optimize Images for Your Website and Make Them Work on All Devices

Table of contents:

👋 Why listen to us?
Images have been a critical topic for us lately, and that’s because of one of the newer tools in our family – Optimole.
Optimole is a set-it-and-forget-it image optimization service & tool. We consider it to be the best such solution on the web, and we can prove it! But that’s a talk for another time. Either way, over the years, we’ve learned a lot about how to optimize images properly. We want to share some of that knowledge with you today.

🤔 Why you should optimize images on your site
Images, apart from looking great, also consume a significant amount of disk space and bandwidth. More specifically, images account for anything from 30%-85% of the size of a standard web page.
speed test
That is huge – and it’s not like removing images is an option – so the best thing we can do instead is learn how to optimize images in a way that simply takes up less disk space.
The gains can be huge, and especially when dealing with repeated images – images that need to be loaded on every individual web page. Those are things like backgrounds, design elements, logos, icons, etc. Sometimes optimizing just one background image can result in cutting your page size by 70%+.
See this example:

page size comparison before and after you optimize images

But hold on, it gets worse! If the general image performance struggles weren’t enough, there’s also the mobile realm 📱, and it brings a completely new set of challenges:
First off, you probably shouldn’t display the same set of images to your desktop visitors and your mobile visitors. The contexts are just vastly different – this includes the screen sizes, orientation (usually in portrait) and even the mindset of the person reading.
Moreover, data suggests that mobile designs with fewer images tend to perform better in terms of conversions.
When all put together, there are a couple of things that we need to take care of when delivering responsive images across multiple devices:

  • first, optimize images for that specific device
  • make sure the images are compressed to the maximum acceptable level to guarantee the fastest loading times
  • display the optimal number of images considering the device and screen

🚶‍♂️ How to optimize images and deliver them across all device types
Getting your images processed optimally and then delivered to the visitor as quickly as possible has several components to it. In this guide, we’ll go through them all:

🍁 Pick the correct format
Let’s start with the age-old question: PNG or JPG?
Most people say “JPG all the time!” But that’s not really correct:
PNG vs JPG
Yes, most of the time, or at least in the most common scenarios for what we might need images, JPGs take up less disk space and therefore less bandwidth as well.
But the keyword here is “the most common scenarios.” In fact, if what you have is a complex image with a lot of colors and color transitions (aka. a lot of “color information”), then JPGs are indeed going to be better. Think standard photos. Those work better as JPGs.
However, if you have an image that’s a bit simpler, PNG will win all the time.
Consider the following example. Here are four images:

image-1-aimage 1-a: JPG

image-1-bimage 1-b: PNG

image-2-aimage 2-a: JPG

image-2-bimage 2-b: PNG

  • image 1-a is 312 KB
  • image 2-a is 196 KB

Try guessing the sizes of the other two images…

Your answer:

Wrong!

  • image 1-b is 1.3 MB (this you’ve probably guessed)
  • image 2-b is 106 KB (wait, what?!)

As you can see, PNG wins for simple, low-color-info images.
Think things like interface screenshots, simple illustrations, etc.

🎓 Lesson #1:
Don’t always go for JPG. Predict how big the image is going to be based on its contents, and then use the correct image type.

Now for a bit more timely question: SVG? WebP?
SVG and WebP
SVG and WebP are a bit less common image types on the web, but they are both great as long as you’re using them as they should be used. Let me clarify:

  • SVG is an XML-based vector image format. The contents of the image can be defined in a simple XML file – the same XML file you’d use for other basic data processing purposes. This makes SVG a good format, as long as you’re dealing with a simple vector image.
  • WebP is a new format by Google. They brag that WebP is 25-34% smaller in size than comparable JPEGs, and 26% smaller than comparable PNGs.

So what’s the catch? Can you optimize images by turning them all into SVGs and WebPs?
First, SVG. Basically, use SVG only if (a) the image can be saved as SVG efficiently, and (b) if you don’t mind people taking that SVG and modifying it.
As I said, SVG is XML-based, which means that modifying SVG graphics is really easy to do. This is not always something you want – especially when dealing with your brand’s logo or other crucial graphics.
In most scenarios, SVGs are not a format you’ll use very often.
Now, onto WebP. The format is great, and in most cases, it does indeed save a lot of disk space just as promised. Check out these two example images:

jpg image example

webp image example

  • the original JPG version is 204 KB
  • the WebP is 58 KB

The trick is that not all browsers support WebP. In fact, you may not even see the WebP image I’ve used above. At the time of writing, WebP works in Google Chrome, Firefox, Edge, and Opera. Of course, the older versions don’t support the format.
What this means in practice is that adding a WebP image isn’t as straightforward as adding a JPG or PNG.
I mean, you technically can use a piece of code like this:

<img src=”cool-pic.webp” />

… but if the user’s browser doesn’t support the format, they’ll see the familiar broken image icon instead.
To effectively use WebP, you should provide fallback images. For example:

<picture>
<source srcset=”cool-pic.webp” type=”image/webp”>
<source srcset=”cool-pic.jpg” type=”image/jpeg”>
<img src=”cool-pic.jpg”>
</picture>

This means a lot more work. Imagine having to build a tag like that every time you want to add a WebP image to a blog post or page. And let me stop you right there, no, WordPress doesn’t support WebP natively, so you will indeed have to do that by hand.
Still, I do recommend going this complicated manual WebP route whenever you’re dealing with images that appear on multiple pages within your site, or images that are huge in size and you need every tool you have to reduce that size some way.
You can save images as WebP in Photoshop, or use a tool like XnConvert (free).

🎓 Lesson #2:
Don’t bother using SVGs at all if you want to optimize images quickly. The time you’ll waste creating them won’t pay off (although feel free to disagree; here’s a good alternative take). PNGs are going to be much quicker to use and not much worse in terms of disk space consumption.
Use WebP when dealing with images appearing on multiple pages or images that are big enough. That is unless you can handle WebP processing automatically, which can be done with some additional tools. In such a case, use WebP everywhere. We’ll talk about that in a sec.

🗜️ Compress images
Image compression is like magic. Let me show you:
This is the same JPG image, only saved at a different level of compression (often referred to as level of quality):

coon-100%100% quality

coon-95%95% quality

coon-85%85% quality

coon-50%50% quality

If you’re like most people then the first three look the same to you. The fourth one starts looking “a bit worse.” (Right click and “Open Image in New Tab”)
Here’s how much disk space each of these images takes:

  • 100% quality: 969 KB
  • 95%: 439 KB
  • 85%: 186 KB
  • 50%: 102 KB

Huge, right?! You can go from ~1 MB to ~500 KB with no noticeable loss in quality at all, just by changing the compression from 100% to 95%.
This JPG compression can be handled fairly automatically by various tools, which is great news. However, not all images are created the same, so sometimes you might get okay-looking images next to bad-looking images even though they underwent the same compression process.
Overall, you can take a leap here and downscale the quality of your JPGs pretty heavily. The truth of the matter is that your site visitors don’t care for crisp images everywhere.
Okay, I should clarify; yes, when you want to show them something – like an image that’s key to a piece of content, e.g., product images, hotel room photos – then sure, those ones should be crisp.
But in other areas, you can be a bit more relaxed. For instance, backgrounds don’t need to be 100% crisp. In general, all images that the visitor is not directly engaged with can be lower in quality.
Two of my favorite tools that can help you here are:
ImageOptim for desktop compression on Mac. You can just grab an image from the desktop, drag and drop it onto ImageOptim, and then the tool does its magic and overwrites the source image when done.
Then, you can get that image and upload it to your site normally.

ImageOptim - great tool to optimize images on your desktop

The second tool is Optimole. This tool pretty much redefines how handling images is done on websites. For the purpose of this discussion, let’s just say that it’s really effective when you want to optimize images that are in your media library.

optimole - great tool to optimize images in the cloud

Now onto PNGs. Just like JPGs, PNGs can be compressed as well. But this time, there’s no downside in terms of loss in quality. PNGs can be compressed effectively using lossless algorithms.
In other words, compress your PNGs, always!
Check out these three images:

kwf-1

kwf-2

kwf-3

They look the same, but they actually take up:

  • 346 KB
  • 215 KB
  • 100 KB

Try guessing which is which.

Three tools to compress your images and make them smaller:

  • ImageOptim again. But this one takes a lot of time with PNGs, so if you have many of them to process, you might want to make yourself a cup of coffee while the tool is working.
  • ImageAlpha. Much quicker than ImageOptim. It’s my go-to desktop solution for PNGs.
  • Optimole. Unsurprisingly, Optimole handles PNG compression as well. Everything happens on autopilot.

🎓 Lesson #3:
Compress your JPGs to reach an acceptable level of quality vs disk space.
Compress your PNGs always.

📏 Serve images of the correct dimensions
This is perhaps the most crucial aspect of the whole “responsive images” riddle. As we know, there are tens if not hundreds of different screen sizes out there, and we somehow must make sure that our images are going to look great on all of them.
The easy solution? Serve a big image … it can always be scaled down, right? Well, technically, that is correct, but in practice, this will waste a lot of bandwidth and make your site load really slowly on most devices.
A better solution is to scale all images to the correct sizes that are preferable by the most common devices and then serve them accordingly.
As you would expect, you do need different versions of the same image to achieve this.
One of the ways to go about this is to start with your design’s base width and the biggest image size that can be used, and then scale down from there for some common devices and breakpoints.
For example, most websites don’t go above the 1100 px mark for content block width, so you can assume that the max image that can be displayed in that case is 1100 px in width as well.
Then, you can create breakpoints for 800 px and 550 px (common values) to cover tablet and mobile scenarios. While this won’t give you 100% perfect results on all devices, you’re at least optimizing to a reasonable extent and keeping your images under control.
With this behind you, you now must create a handful of different versions of each image that you want to use on your site.
Here’s an example of how to handle the actual display code:

<img src=”image.jpg”
srcset=”image-550.jpg 550w,
image-800.jpg 800w,
image-1100.jpg 1100w”
sizes=”(max-width: 1100px) 1100px, 100vw” />

The magic of the srcset attribute is that the browser looks at what’s in it and then picks the best image based on the device being used.
One more customization that you can see above is the sizes attribute. This one tells the browser how the image should behave on certain screens. In this scenario, the image is going to be 1100 px when viewed on viewports larger than 1100 px, while on smaller devices it’s going to take up the whole viewport.
This sort of solution makes sure that the image doesn’t take up a whole 3840px-wide 4K screen. However, it will still occupy the entire screen when viewed on mobile.
This effective use of the sizes attribute is how you make your images truly responsive.
⭐ Pro trick: Go for images that are 10% smaller in dimensions than what’s needed, and then let the browser scale them up. This will save you some additional space and bandwidth. For example, if you require an image that’s 500×500 px, you can scale your image to 450×450 px, and then let the browser scale it up to 500. This does depend on the image, but in most cases, the user won’t notice.

🎓 Lesson #4:
Use the correct image sizes for your design.
Create breakpoints.
Create multiple versions of the same image to cover the breakpoints.
Use the srcset and sizes attributes when displaying the images.

📺 Optimize images for Retina and HiDPI screens
The other end of the image dimension spectrum is about HiDPI-friendly images.
The story is that desktop screens keep getting bigger and bigger, and their pixels keep getting packed more and more densely. It’s not uncommon these days to have a 4K screen packed into a 15-inch laptop. The 4K resolution is 3840×2160 px, so each of those pixels has to be really tiny.
This creates problems for websites. Basically, if your site was defined as 1100 px wide then, under normal conditions, it would only take up roughly 25% of the available screen real estate of a 4K screen. This is not optimal. Luckily, things don’t work like that.
To avoid the issue, those high-res screens act as if they were half the size (I’m oversimplifying, but hear me out). So, instead of your 1100 px wide website occupying a small portion of a HiDPI screen, it gets scaled up to double that, taking up 2200 px and filling the screen much better.
This process allows screens to keep getting sharper and sharper without making everything look tiny in the process.
However, this practice is not without its faults. Chiefly, your images take a huge hit. Text is easy to scale up without losing quality. Fonts are immune to scaling. Images are not. As a direct result, every image that’s not ready for HiDPI screens will look blurred, heavily!
To fix that, you must deliver scaled images for each of the zooming ratios. Here’s some simple code:

<img srcset=”img-orig.jpg,
img-2x.jpg 2x,
img-3x.jpg 3x”
src=”img-orig.jpg” />

(If the browser doesn’t support srcset, the standard src will be used.)
Now, when I say “scaled images,” I actually mean that you should start from the other end. Begin with a huge image (label it 3x), then scale it down and make it smaller (to 2x), and finally make it 1x and use that as the default image.

🎓 Lesson #5:
Make sure your logos, branding images, and all images used in your posts and pages are ready for HiDPI screens.

⌛ Defer image loading
This is simple in principle; all images that are above the fold should be loaded immediately (on page load). Everything else can be deferred for later, and even “lazy loaded.”
Lazy loading is image loading on demand. I.e., images get loaded only a split second before the user needs them – not sooner, not later. And that “not sooner, not later” part is key here.
In an ideal scenario, the image should be loaded just before it gets scrolled into the viewport. Meaning, the user shouldn’t have to see a placeholder before the image appears. If that happens, they might scroll pass the image without it managing to load in time – not a great way to optimize images.
That being said, lazy loading is something easy to do on WordPress sites. You can lazy load with JavaScript / jQuery, and you can even write the code for that yourself if you want to. Alternatively, you can get a plugin like a3 Lazy Load, or you can use Optimole, which has a lazy loading module included.

🎓 Lesson #6:
Lazy load images that are below the fold.

🌐 Deliver images via a CDN
A Content Delivery Network is like a cheat code for site speed. You’re cheating because you’re not as much making your site faster, as you’re telling someone else to take the load and deliver the site’s data to the visitor for you.
👉 We talked about CDNs more in-depth here, check it out.
The TL;DR is that CDNs take advantage of a network of servers that all hold a copy of your site and then deliver it to the visitor from the nearest available location. This is always going to be faster than delivering from your main server.
Image CDNs work pretty much the same, but they focus only on, you’ve guessed it, images.
Most of the time, the operation is seamless from your point of view. All images on your site get replaced by their CDN-hosted versions (meaning that the image URLs change).

  • Jetpack has a popular image CDN built right in. You can use it for free, which is great. The main limitation is that it only works with the images in your posts, pages, and your featured images. It doesn’t work for any images that make up your design (parts of the theme, layout, etc.). Those are the images that could really use some CDN-ing.
  • Optimole has a CDN built-in as part of the main image optimization feature. This one is not limited to your posts and pages only.

🎓 Lesson #7:
Hook up your site to an image CDN (Jetpack or Optimole) or a general CDN (MaxCDN / StackPath).

🐌 Serve smaller images to users on slow connections
Not only screen size matters when deciding what type of image the user should see. Probably even more importantly, if they’re on a slow internet connection, they really don’t want to wait 10 seconds for an image to load.
In these scenarios, it’s a lot better idea to downgrade the quality of your images in exchange for load time. Users on slower connections will appreciate that they can see the images at all.
You can make this happen by utilizing the Network Information API. Here’s a cool tutorial on how it all works if you want to implement it by hand.
If you’d prefer it to be handled on autopilot, again, Optimole!

🎓 Lesson #8:
Serve smaller and more compressed images to users on slower internet connections.

Along the way, I mentioned a number of tools that you can use to make your site’s image delivery more effective. Here’s a summary of those:

  • Optimole – lets you optimize images automatically, compresses them, picks the right image size for the visitor’s viewport, serves image via a CDN, lazy loads images, works with slower connection speeds.
  • ImageOptim and ImageAlpha – handle desktop image compression on Mac. You can use TinyPNG on Win. Do that before uploading images to your site.
  • XnConvert – lets you convert images to WebP.
  • a3 Lazy Load plugin – lazy load all images.
  • Jetpack plugin – comes with a free image CDN.
  • MaxCDN / StackPath – a general CDN that will take care of your whole site, not just images.

tools to optimize images

📚 Further reading:

🤷‍♂️ TL;DR:
Here’s a summary of all the individual lessons shared above:

Lesson #1:

Don’t always go for JPG. Predict how big the image is going to be based on its contents, and then use the correct image type.

Lesson #2:

Don’t bother using SVGs at all if you want to optimize images quickly. The time you’ll waste creating them won’t pay off (although feel free to disagree). PNGs are going to be much quicker to use and not much worse in terms of disk space consumption.
Use WebP when dealing with images appearing on multiple pages or images that are big enough. That is unless you can handle WebP processing automatically, which can be done with some additional tools. In such a case, use WebP everywhere. We’ll talk about that in a sec.

Lesson #3:

Compress your JPGs to reach an acceptable level of quality vs disk space.
Compress your PNGs always.

Lesson #4:

Use the correct image sizes for your design.
Create breakpoints.
Create multiple versions of the same image to cover the breakpoints.
Use the srcset and sizes attributes when displaying the images.

Lesson #5:

Make sure your logos, branding images, and all images used in your posts and pages are ready for HiDPI screens.

Lesson #6:

Lazy load images that are below the fold.

Lesson #7:

Hook up your site to an image CDN (Jetpack or Optimole) or a general CDN (MaxCDN / StackPath).

Lesson #8:

Serve smaller and more compressed images to users on slower internet connections.

Let me know what you think of the whole challenge to optimize images for the web as much as possible. Also, what are you doing with your images to make them load faster? Share in the comments.


Don’t forget to join our crash course on speeding up your WordPress site. With some simple fixes, you can reduce your loading time by even 50-80%:


Layout, presentation, and editing by Karol K.
* This post contains affiliate links, which means that if you click on one of the product links and then purchase the product, we’ll receive a small fee. No worries though, you’ll still pay the standard amount so there’s no cost on your part.