Images are the largest asset on your website, on average making up over 62% of a website. As such they are one of the main things you should look to optimise. Photographers and graphic designers want the highest quality images to show off their work, but those that surf the web would almost always prefer the website to load quicker. When even the most basic smart phone can take multi-mega pixel images, it is important to ensure your images are appropriately sized and optimised.
How to set it up
Images can be optimised, firstly by ensuring you choose the right format, and then by ensuring that the best options are used to save in that format.
- Joint Photographic Experts Group format (.jpg or .jpeg)
- Photographs and very rich pictures.
- Graphics Interchange Format (.gif)
- When you want simple animation.
- Portable Network Graphics format(.png)
- Screenshots and other diagrams. Also allows transparent backgrounds which can be useful for icons.
- Scalable Vector Graphics format (.svg)
- Icons and simple drawing that can be described in a list of instructions. Will scale to all screen sizes without losing clarity, but is not supported by Internet Explorer 8 or below.
- Bitmap format (.bmp)
- When you hate your users and would prefer them to load every single pixel down cause you really can't be bothered to spend a little time to find a better format. So basically don't use it :-)
There are also other, newer, image formats like WebP, but they have little support at present, so the above are the main formats you will use for now.
Even once you've chosen your image format correctly there are a number of options you can use when saving the data:
- Quality: JPEGs in particular can be saved in various quality levels. The lower quality, the lower the file size, but the more pixelly the picture will look.
- Resolution: If you are showing an image which is 20 pixels by 20 pixels on your website there is no point in uploading the image in 2000 pixels by 2000 pixels and making the browser shrink it down. This is a waste of both network bandwidth and client resources (to store it in memory, shrink it down for display, cache it...etc.). The only thing to be aware of here is that increasingly high end devices have more pixels then they typically admit to, so they can make more use of higher quality images, though typically anything more than double the typical screen pixel resolution is unlikely to be noticeable by most users.
- Colour Depth: Some formats (especially .gif and .png) have a number of colour depths. This is the total amount of colours available to the image. The more colours, the larger the file size (even if you don't use those colours). So if you have a black and white image, then you can save it as PNG-8, rather than PNG-24 which will save a lot of space for no difference in quality. The one thing to note is that only PNG-24 natively supports the transparent option that makes PNG so useful for icons.
- Progressive vs Baseline jpegs: Traditionally images load line, by line. This means a slow loading image will slowly load from top to bottom. Progressive JPEGs instead have the image stored in a different way where the whole image is drawn initially but with very little detail, as more and more detail is loaded the image, appears to come into sharper and sharper focus until it's completely loaded. Even though progressive JPEGs are usually slightly larger than traditional baseline JPEGs they are usually seen as giving the appearance of being more performant (though there is some argument that this may not be the case). Ultimately it's a personal choice as to whether to use them or not (personally I prefer them).
- Meta data: Some image formats contain a lot of meta data (when the picture were taken, where, with what lenses...etc). This data is unlikely to be useful except on dedicated photography sites, so for most images on most sites his is wasted data and can be removed to save space.
I've optimised all the images on this website using TinyPNG (also hosted under TinyJPG) which literally took just a few mins to drag them on to the website, watch as they optimised in seconds, download the results, and then upload to my web server. Most images dropped in size by 50% or more and looking at the images I can't see any difference. A very easy, once off speed gain for your readers!
The growth of multiple screen sizes, from huge desktop monitors, to tiny mobile screens and everything in between makes this even more tricky. While it might seem simplest to put the largest image size needed, and have the browser automatically scale down for smaller screens, this will basically penalise your mobile users. There are a few ways to add responsive images to your website, and this deserves a larger blog post, but for now I'll mention the two ways I recommend most:
- The <picture> tag allows you to specify multiple images and let the browser choose which ones it wants to use depending on screen size. It's support is limited at present, but it's possible to add a fall back:
<picture> <source media="(min-width: 1200px)" src="large-desktop-image.jpg"> <source media="(min-width: 600px)" src="small-desktop-image.jpg"> <source src="mobile-image.jpg"> <img src="small-desktop-image.jpg" alt="Fall back image for older browsers"> <p>Text for screen readers.</p> </picture>
- Images can be set with CSS. Browsers will not download the background image if the parent tag is hidden (though they will if the actual tag is displayed). So you can use this to create responsive images with code like this:
<div class="LargeImageHolder"> <div style="background-image: url('/images/large-image.jpg')"></div> </div> <div class="SmallerImageHolder"> <div style="background-image: url('/images/smaller-image.jpg')"></div> </div>Then it's just a matter of using "display: none" on LargeImageHolder or SmallerImageHolder class.
The other thing to remember is that, where possible, to set the height and width of the image in the image tag. This will allow the browser to set aside the space for the image before the image is downloaded. This will stop the page being redrawn after the image is downloaded so will look better for the user.
It's also worth remembering that, while it's always better to reduce file sizes to save bandwidth and resources (on both the server side, and the client side) a lot of performance problems are caused by network latency rather than bandwidth so it's the number of files which can cause performance problems. One large image will be slow to load, and should be optimised, but often the problems of images are due to the sheer volume of them. There are other ways to get around this, including Caching, spriting, using inline graphics.
Support for all the main image formats shown above is pretty much universal. As mentioned above, some newer formats like WebP have less support and, while they may be the format of choice in future, for now it's probably best to stick with above formats.
The main downside to optimising images is the time it takes. It's always easier to upload an image you get straight from your designers. And if you have multiple people with access to upload images (e.g. IT department, marketing department and potentially other areas of the business), then it may be difficult to explain to everyone the importance of this step, as well as the skills needed to do this. Few people are Photoshop experts.
The other issue is that a poorly optimised image will look pixelly and will potentially make the whole website look like it is low quality.
On most website images are larger than all the other resources combined. Therefore they can be one of the most obvious places to focus optimisation resources. This is especially relevant for home pages, which often contain large banner images. Saying that, a lot of the problems with images taking up a lot of a page size, are due to multiple images and in these cases, ven optimising the images, will not lead to a massive performance benefit as you will quickly reach latency limits where the number of resources, rather than the size of each resources are the limiting factor. A future post will explore how to improve on that.
This page was originally created on and last edited on .Tweet