I get asked a lot about why one can compress all their images on Maximum Lossy with EWWW I.O. and still have those images show up on Google’s PageSpeed Insights. I’ve explained a great deal about the technical aspects of the problem elsewhere. I’ve also included some of that information in our documentation to help folks understand why retesting with PSI can lead to false positives.
But every time I see this question, an analogy comes to mind, which can help to understand the difference between PSI compression (using ImageMagick), and EWWW IO (using TinyJPG/TinyPNG). So, without further ado, I give you the chisel vs. the chainsaw:
Using a tool like ImageMagick is like using a chainsaw to compress your images. It’s fast, but rough around the edges, and leaves a noticeable impact on your images. Using EWWW IO, with the industry-leading TinyJPG compression, is like using a chisel to sculpt your image precisely to the best quality and compression level. It takes longer, sometimes a lot longer, but the end result is a finely-tuned image where the compression is not noticeable. Also, it’s automated, so you don’t actually have to do the hard chisel-work yourself.
If you use a tool like PSI to test the compression of your hand-chiseled images, what would happen? Well, PSI starts off with the assumption that everyone is using chainsaws on their images. It looks for those noticeable changes (often referred to as “artifacting”), and attempts to calculate the quality of the image based on the effects of using a chainsaw. It’s looking for the rough edges to tell how much compression was applied. But if you’ve used EWWW IO, there will be a serious absence of rough edges, and that’s why PSI can fail to detect when EWWW IO has already compressed an image. Could we compress it farther, since Google thinks your visitors will be OK with chainsaw-compressed images? Certainly, but who wants to have chainsaw images when you can achieve the same (or better) compression with the chisel that is EWWW IO?
There is another wrinkle to this story if you’re using WordPress, and PSI is complaining about a resized image, and not the full-size original. For example, if it lists http://example.com/wp-content/uploads/image-600×450.jpg as opposed to http://example.com/wp-content/uploads/image.jpg. As you may know, a resize is compressed to quality 82 when it is saved, unless you change the default quality within WordPress. So all the resizes on your site have likely already been chainsaw-compressed (the PSI quality recommendation is 85). Even better, WordPress supports the same chainsaw that PSI uses, since it uses either GD or ImageMagick in the compression.
So how does a resize, that was already chainsaw-compressed, at a lower quality level, show up in the list of images needing more compression? When you use a chisel, you smooth out some of the rough edges (those pesky “artifacts”) from the chainsaw. Even though the image was already banged up by the chainsaw, using the chisel makes it so PSI can’t tell a chainsaw was used on the image originally. PSI can’t find those rough edges, thus it fails to detect the how much the image was already compressed, and it tells you that you should still compress your image further. Crazy, eh?
What are you waiting for? Toss that chainsaw out the window and grab yourself a chisel!