When it comes to improving a website's performance, ensuring that images are formatted and compressed correctly can often result in big improvements — dramatically reducing load times and speeding up rendering.
Page speed is important to user experience. Pages with a longer load time tend to have higher bounce rates and lower average time on page. Longer load times have also been shown to negatively affect conversions. With this in mind, and with Google's shift towards page speed as a major factor in site rankings, it was time to take a look at our image optimisation processes here at Kyan and where we could make improvements.
Format first
The first step in any image optimisation job is selecting the right format. There's no one-size-fits-all solution for this. Each image (or set of images) should be considered on an individual basis.
Finding the optimal format and optimization strategy for your image assets requires careful analysis across many dimensions: type of data being encoded, image format capabilities, quality settings, resolution, and more. In addition, you need to consider whether some images are best served in a vector format, if the desired effects can be achieved via CSS, and how to deliver appropriately scaled assets for each type of device.
Google Page Speed Insights
That's a lot to think about. So, as a quick rule of thumb:
- If it's a photo: JPEG
- If it's a photo requiring transparency: PNG
- Graphics: SVG
Once the format is decided, then it's time to look at compression algorithms, resolution, quality etc…
JPEGs
JPEG modes: Baseline (sequential) vs. Progressive
There are two different methods of encoding JPEGs, and there are file size savings to be made by selecting the right one.
Baseline JPEGs are encoded and decoded in a relatively simple manner: top to bottom.
Baseline JPEGs load from top to bottom
Progressive JPEGs divide the image into a number of 'scans'. The first shows a pixelated or blurry version of the image, and following scans improve in quality as the image continues to load.
Progressive JPEGs load from low to high quality
PJPEGs can improve compression, consuming 2–10% less bandwidth.
Twitter, Facebook (iOS app), Yelp and Pinterest use progressive JPEGs in production. Facebook found it reduced data-usage by 15%.
Any disadvantages of PJPEGs?
PJPEGs can be slower to decode than baseline JPEGs — sometimes taking 3x as long. On desktop machines this is less of a concern, but may be an issue on mobile devices.
Progressive JPEGs are not always smaller. For very small images (like thumbnails), progressive JPEGs will often result in a larger file size, so switch back to baseline for anything under ~10KB.
JPEG compression algorithms
There are a number of different compression libraries available for JPEGs, so we put a few of them to the test on a set of images featured in one of our project case studies on the Kyan website. Like most of our case studies, the page is image heavy in order to show off our work, and we were interested to see what kind of file size savings we could achieve.
Figures in grey across the top indicate quality settings used (where available). Figures in grey across the bottom indicate the resulting total image folder size in KB, and as a percentage size of the original Photoshop save-for-web JPEG exports at 80% quality.
Google Guetzli
Google Guetzli is a new (2017) JPEG compression algorithm, with a big headline… 35% smaller JPEGs without loss of quality!
The reality…
- Compression is incredibly slow and processor-intensive (several hundred to a thousand times slower than other encoders).
- Doesn't support progressive encoding
- Quality can't be set lower than 84/100
- Strictly sRBG only
Recommendation
Best reserved for small-batch or single-image compression where quality is paramount and size is critical — but also worth checking size against JPEG-Recompress output.
JPEG-Recompress
Lightning fast, and with highly impressive results is jpeg-recompress, which can batch process images from the command line, and has useful options for customising the compression process to fine-tune results. Uses MozJPEG under the hood.
Jpeg-recompress works by iterating over an image within a default quality range of 40 to 95 to find the best compromise between quality and file size. You can specify the amount of loops, but the default (which is usually sufficient) is 6. Progressive encoding is enabled by default.
Recommendation
Jpeg-recompress was the clear winner, and has now become our standard method of JPEG compression for production. The results are significantly smaller files with almost no discernible loss in quality.
PNGs
Similarly to JPEGs, there are a range of tools available for compressing PNGs. A recent Kyan project featured a number of hero banners that required photographic images with transparency, and we ran these through each tool to see what kind of file size savings could be made.
TinyPNG produced the best results, closely followed by online service Optimizilla.com, and PNGquant.
TinyPNG
There are a couple of options for processing images using TinyPNG. The online service is limited to 20 images at a time, with a 5MB file size limit. If that's too restrictive for your needs, they also offer a developer API — the first 500 images a month are free.
Recommendation
TinyPNG produces the best results, but if you're likely to exceed 500 images a month and don't want to start paying a per-image fee, PNGquant is a decent fallback.
Enter WebP
WebP is a recently introduced image format from Google, aiming to offer lower file-sizes for lossless and lossy compression at an acceptable visual quality. It includes support for alpha-channel transparency, which makes it a viable replacement for both JPEGs and PNGs.
WebP has arrived.
WebP vs. JPEG
WebP lossy files are on average cited by the WebP team as being 25–34% smaller than JPEG files. We converted our case study page images to WebP for a comparison against JPEG-Recompress output:
Impressive savings with WebP, and our images still look great.
WebP vs. PNG
WebP lossless files are on average 26% smaller than PNG files. That said, WebP compression involves some blurring effects, so sharp edges may be lost. We ran a comparison on the header images we compressed earlier using TinyPNG.
Outstanding results for PNG to WebP conversion.
The team felt the WebP images were of a higher quality, having retained more colour depth, and the edges still look crisp.
Who's using WebP in production?
Google reported 30–35% savings using WebP over other lossy compression schemes, serving 43 billion image requests a day, 26% of that being lossless compression.
Netflix, Amazon, Quora, Yahoo, Walmart, Ebay, The Guardian, Fortune, and USA Today, all compress and serve images with WebP for browsers which support it. VoxMedia shaved 1–3s off load times for The Verge by switching over to WebP for their Chrome users. 500px saw an average 25% reduction in image file size with similar or better image quality when switching to serving it to their Chrome users.
WebP browser support
Currently, only Chrome and Opera natively support WebP, but between just those two, CanIuse.com estimates that puts global user support at about 72%. Not a figure to be sniffed at! Taking the file size savings into account, it's well worth implementing WebP images for your site, along with a fallback solution.
Any drawbacks?
WebP doesn't support progressive decoding.
Converting/Exporting your images to WebP
It's important to avoid converting low quality JPEGs to WebP — always feed conversion apps the best quality source file available, preferably the original.
osX
OsX doesn't natively support previewing WebP images in Finder, which can be a pain. Add support for previewing WebP images with WebPQuickLook.
NOTE — there are very noticeable colour and brightness differences when comparing source images and output WebP files if previewing in Finder. Viewing in Chrome gives a more accurate comparison.
Sketch
You can export WebP out of Sketch, straight out of the box.
Batch Conversion (GUI)
Check out XnConvert or WebPonize.
CLI
Head over to Google's developer page for WebP to get tooled up.
Using WebP in HMTL & CSS
Jeremy Wagner has got this covered over at CSS-Tricks.
SVG
Compressing your SVGs can yield big file size savings, and there's an excellent tool for this called SVGO. Beyond compression, SVG assets can also be GZipped/Brotli'd, which saves loads more KB.
- OSX Folder action
Automatically process any files added to a specified folder. Just set it up at the start of a project and never have to think about it again! - SVGOMG online GUI
One at a time, but you can see/check the results and tweak settings in real time, and flip between the output image and the code. - Node-js Module
- Grunt task
- Gulp task
- Webpack loader
- PostCSS
Optimise inline SVG.
Putting it to the test
We processed an SVG sprite from a recent project through SVGO and compared it against the original output from Sketch:
SVGO produced a file size reduction of nearly 60%.
What about GIFs?
Animated GIFs tend to be very large when compared to the file size reduction that be achieved by converting to video. Delivering the same file as an MP4 video can often shave 80% or more off your file-size. To test this, we grabbed a selection of GIFs from a quick Google search and ran them through FFMPEG to see how much we could shave off the file sizes:
We achieved almost 90% file size reduction in total by converting GIFs to MP4s.
Summary
Image compression is a biiiig subject, and we certainly haven't covered every aspect of it here, but having discovered our preferred compression methods across each file type, these are the new guidelines for image compression at Kyan:
- Serve WebP down to browsers that support it for JPEGs and PNGs.
- Fallback JPEGs should be compressed with JPEG-Recompress.
- Fallback PNGs should be compressed with TinyPNG.
- Compress SVGs with SVGo.
- Convert GIFs to video (ideally H264 .mp4, or WebM if you can build in fallback support)
Following on from this discovery phase, our thoughts have now turned to automating all this processing in the background during development, and we're currently working on a Gulp task to do just that.
To be continued.
Due credit
A lot of this research was informed by Addy Osmani's outstandingly comprehensive eBook on the subject — Essential Image Optimisation — highly recommended if you'd like to know more.
