Speed is one of the most important factors of your website. Did you know that half of the mobile visitors will leave a website if it doesn’t load within three seconds? Suppose it would be good to check if you can squeeze something extra of that fancy background picture you have. But when should you optimize it? You will need to learn how to spot if the compression is pushed too far, or if there’s still room for improvement. The errors introduced by compression differ from one format to the other, we will cover them below.
Is the image size correct?
First of all, let’s check if the image size is defined correctly. What I mean is, when you only show your image within a wrapper that limits its width to 1200 pixels, there’s no need to load a larger image.
An exception is a high-density screen like Mac’s Retina where we can load an image that’s 2400 pixels wide. However, remember that the image consists of not 2, but 4 times as many pixels so it will also be around 4 times heavier! You should load these images only when a high-density screen is detected, using either the
Which file format to choose?
Make sure the file format you’re using is the best one for its job. So which one should it be?
- Photographs, complex illustration with lots of gradients - JPG
- Simple gradients - PNG
- Illustrations, logos, icons - solid colors - PNG
- Same but you have it in vector? - SVG
There’s also WebP, but I did not include it on purpose. The compression algorithms I’ve used offer similar effects, with 100% browser support. Also, no GIF, as PNG compresses better than GIF in almost every case.
When compressing the images it’s best to work with the source file, not the one that’s on your website and might have already been compressed. If someone saved a photograph as a 256 colors PNG you would shave quite a lot KB’s off it by saving it as a JPG, but you would have errors not from one, but from two file formats! Unless glitch art is your thing, I would not recommend doing that. But even if the compression is poor and the file is large, there are already some errors present even if they’re hard to notice.
JPG
So how to spot the artifacts from JPG’s compression? If there’s a lot going on in the image, you might not notice the quality drop. Look for areas that have a solid color or a gradient - like the sky in the example below, where it’s touching the clouds:
It’s the high contrast on the sharp edges that will have the most visible artifacts. Keep in mind to watch how the areas of your picture with red color will behave. This color will be the most noticeable to lose quality:
Of course, each image is different and you might get better results with other formats or settings, but this should get you covered in most cases.
Compressing with Sketch
Sketch offers the Export tool, with a few formats and some customisation, so let’s start with that.
JPG saved from Sketch at 70 - 80% quality barely shows any signs of a quality drop, but it’s fairly large at 312 - 385 KB. Better than no optimisation, but don’t expect a high score from PageSpeed Insights, we will not be using that.
230 - 292 KB. Smaller than JPG 70, and with superior quality. If you want to use WebP, you can make this your default for Sketch exports. But still, you will need to provide additional formats with the
Web compression tools
It’s named TinyPng but it compresses both JPG and PNG. Keep in mind that it will compress to the same file format that you provided, and that the file you feed the Panda with should be saved at the highest quality. Using automatic compression we were able to cut down the size to 230 KB, the same as webP at 85. The quality is fairly good, there’s a bit of color degradation, as the gradient becomes less smooth but it’s acceptable.
Quite the opposite from TinyPng, Squoosh offers a lot of customisation but the setting we’re after is MozJPG - 80 is the recommended minimum (215 KB), up to 85 (255 KB). I’ve set the quality to 82 (233 KB) to match the size closely to the other tools.
How do the 3 contestants compare?
So for the multicolored images, after comparing WebP with TinyPNG’s and MozJPG’s compression, it’s hard to say which one is the winner. Each method has better and worse spots, so if there is no visible advantage of WebP and the browser support is worse, I would not recommend it. I would go with Squoosh and MozJPG, as you have the option for controlling quality if needed.
PNG
How to spot a badly compressed PNG? It’s a lossless compression so it works differently than JPEG. It’s simply missing colors. The errors will appear in the form of dithering, the little dots that try to make up for the not rendered colors. They do a pretty good job preventing banding from occurring, but still, this is not something that we want. It’s very easy to spot on photos, as these should be saved as JPG’s.
This one is also simple in terms of compression, just drop it into TinyPNG and you’re done. The difference is massive, Sketch export of the gradient weighted 187 KB when Panda made it into 8 FREAKING KB! That’s almost 96% compression, fast and effortless! You might reduce the size even further (to one line of code) if it's possible to use the same gradient in CSS.
Don’t even bother with trying to find any difference :)
SVG
Vector images are usually pretty lightweight already, but we can push it a bit further, and of course, you can push it too far as well. Here’s a quick recap from my article SVG Icons — From Sketch to React, check out section Export that will show you how to apply proper compression and spot the bad one.
Happy compressing! :)
