Battle of the Image Compression WordPress Plugins

I’ve long been an advocate of optimizing images for better site performance. I have a short series of articles (of which this is now the fourth) talking about different ways to optimize your WordPress website.

Until now, my recommendation to anyone serious about page speed has been to optimize their images manually. My first article on this, talked about the science behind it and how to do it for free. Next I delved into automation options and highlighted why at that time they were not quite as beneficial as optimizing by hand.

I’m really happy to write this comparison article in order to highlight a couple methods now that do image optimization really well so we can finally have our cake and eat it too when it comes to image optimization.

Different Image Optimization Scenarios

Before I jump into this knock-down, drag out showdown I need to highlight that different websites will have different image compression needs. For example, my site is primarily a blog/portfolio/product site. None of those purposes require high quality images. My image use revolves around supporting my words in a visually attractive way that make people remember the post/page/product. So in my case, I want to compress the H*&^ out of my images to get them as small as possible without looking horrible.

Sometimes though, the quality of the image is paramount. Not just the visual quality, but also the data that each image holds inside it — the EXIF data — is really important. EXIF data holds all kinds of useful information about an image.

A professional photographer, for example, might want to make sure that any photos they post on their site keep the EXIF data in tact so their visitors can see the various camera settings, the camera model, the lens, or other useful data about what it took to take that shot. To see what this looks like live, download some images from Death to Stock, and install this Chrome Extension and you can see all the crazy info saved inside each of their photos.

Another scenario is a product-based website. Perhaps you’re selling furniture with WooCommerce on your site. You hired a professional product photographer to get excellent shots of all your stuff. You even installed a little image zoomer extension so users can get an up-close and personal look at the gorgeous details of your product. In this case you don’t care about EXIF data at all, strip that stuff out! But you do want to make sure the seems of your hand-crafted chair show up clearly when zoomed in.

Lossy and Lossless Compression

In that case you will only be interested in “lossless” compression. You’re in luck, this whole review really focuses only on lossless options. The opposite of “lossless” compression is called “lossy”. Lossy compression basically analyzes your image and tries to pull out as many similar colors as possible in order to reduce the actual data that creates the image. This means that it attempts to throw out as much data as it can while keeping the general appearance of the image in tact. This is very effective in getting smaller images, but the downside is that the final result is often a loss of the visual quality of the image.

Lossless on the other hand, does not throw out any of the data that creates the image. The science of it is really complex, but the idea is to make an algorithm that represents that image as simply as possible for your browser to recreate. Think of it like creating a zip file. You take a whole bunch of files and combine them all into a much smaller zip file. But once that zip file is unzipped, all the data is available to you again exactly as it was before it was zipped. That’s what lossless is doing to your images.

There are circumstances when doing lossy compression makes a lot of sense and doesn’t negatively hurt the image noticeably at all. I find though, that those scenarios are few and far between. So for the sake of the most applicable method, and for simplifying the testing environment, this comparison is only concerned with lossless compression.

Our Contenders

EWWW “the Hammer” Image Optimizer is the reigning champ of WordPress users. Between it’s standard and “Cloud” versions of the plugin, it boasts over 100,000 active installs.

This round only concerns the standard plugin. It should also be noted that this is the only plugin in this showdown that does all of the compression directly on your server.

Kraken “the Shipwrecker” Image Optimizer is often referred by some as the “professional” way to automate your image optimization. The WordPress plugin boasts over 4,000 active installs. The plugin is simply enables the SaaS (software as a service) platform to communicate with your website to upload the images to its service and then over-write your media library with the newly optimized images.

TinyPNG “the Giant” Image Optimizer is another SaaS service. This is the youngest contended in this showdown. Released in early February, 2015, it already boasts 800+ active installs. Despite it’s name, it optimizes both PNG and JPG files losslessly.

Wait… Someone’s missing!

Here’s a few other contenders I decided not to include in this match-up:

1. WP Smush.It. Truthfully, there’s just no need to use this plugin anymore at all. First off, the free version can only optimize images less than 1MB. Then even with the Premium version, you can only optimize images less than 5MB in size. Plus, in the tests I ran previously, it’s compression was pretty much equal or slightly worse than EWWW.
   UPDATE: This plugin has been revamped from the ground up. I haven’t tested it yet, but here’s a new review on it which might make you (and me!) reconsider it as a contender again.
2. ShortPixel Image Optimiser — This is another new kid on the block. Besides their inability to spell “Optimizer” correctly**, I felt it would be more fair to review them on their own in a future post. So watch for that.

**I was informed from various folks in multiple mediums that “Optimiser” is perfectly correct. Apologies for my American “arrogance” (as someone put it). The truth is, subtle humor doesn’t translate well in print. You’d probably have to know me to know I wasn’t serious about that whatsoever.

https://www.mattcromwell.com/promotion/get-analytify/

The Boxing Ring

Every good competition needs to have a regulated and consistent environment. Here’s the stage of our rumble:

Hosting Environment

I put together a quick install on Cloudways. It’s run on Digital Ocean in a datacenter in San Francisco. Cloudways is great for putting up really quick WordPress installs that are optimized for speed. Their default install has W3TC pre-configured to optimize their environment. It also runs Varnish and Memcached by default. For this test I disabled all of that so it didn’t affect the page load times at all.

WordPress Environment

The only other plugin I had installed and running was iThemes Security (I don’t run anything live without that installed and configured). I installed Twenty Twelve to display all the images as well. Sidenote: Twenty Twelve is still bar none the best default theme for testing purposes that WordPress has put out.

The Images

I had two sets of images that I tested each plugin against.

1. The Theme Unit data set has 45 images. None of them are particularly large, but they have a good variety of image sizes with different amounts of color in them. In importing the Theme Unit data, it creates a page called “Post Gallery Format”. That page is intended to show you what your theme looks like with the Gallery Post Format enabled. It therefore has 25 images loaded on it in varying sizes and alignments. That made for a great test page. Without optimization, that page contained 481.9KB of image data. Not a whole lot, but I thought that combo of 25 images with not a lot of weight was a fairly typical scenario to test for.

2. 

   After I ran the optimization test on the Theme Unit data, I took 5 JPG images from Death to Stock and uploaded them directly through the Media Library “Add New” tool. Their total unoptimized size was 43.6MB (each was around 9MB). This was useful since the Theme Unit images were not uploaded via the Media Library, and they were much larger. I then insert all of those images in their original size onto a page. Twenty Twelve automatically keeps them shrunk to the content area, but they were output in full, which naturally made the original page load time extremely slow.

The Methodology

Once all the images were uploaded, I did the following as a benchmark and then repeated this same process for each Contender.

1. Went to the Post Gallery Format page, opened Chrome Dev Tools, went to the “Resources” tab, and entered and calculated the total file size of all the images on that page.
2. Ran Webpagetest.org from a New York location on that page and took screenshots of the Summary page. I used that to report on the First View fully loaded page speed time, and — just to cross-check — checked the image file size reported there with what I calculated in Chrome Dev Tools.
3. Then I uploaded the Death to Stock images and timed how long it took. Each plugin optimizes the images upon upload. So this was important information for the ease of use evaluation.
4. I then visited the page where all those images were output and entered their sizes and calculated the total.

The great thing about using the Theme Unit data was that in order to prep for the next test all I had to do was select all in the Media Library, click “delete permanently”, then re-import the Theme Unit data and now I had all the same images in their original un-optimized condition. Same with the Death to Stock images.

The Results

This table represents the Theme Data Unit results from the Post Gallery Format page.

PLUGIN	Total Size of All Images	% Savings	PageSpeed
Benchmark	481.9KB	NA	2.2s
EWWW with EXIF	471.4KB	3%	2.1s
EWWW w/o EXIF	270.9KB	44%	1.8s
Kraken.io	274.8KB	43%	1.8s
TinyPNG	260.8KB	46%	1.7s

This table represents the Death to Stock images and the page they were output on.

PLUGIN NAME	Total Image Size	% Savings
Benchmark	43.6MB	NA
EWWW with EXIF	39MB	11%
EWWW without EXIF	39MB	11%
Kraken.io	38.6MB	11.%%
TinyPNG	3.12MB	93%

These are the results of uploading the Death to Stock Images in the Media Library. It was 5 images at 43.6MB total.

1. EWWW Image Optimizer = Less than 5 minutes. The results were the same when removing the metadata and not.
2. Kraken Image Optimizer = Roughly 7 minutes.
3. TinyPNG = 10+ minutes

The Post-Match Analysis

Now, what really matters in all this is not just the results, but what it means. It’s really easy to look at that data and conclude that TinyPNG is the easy and clear winner. But the whole reason I mentioned the various image optimization needs is because in this case — the devil’s in the details.

Regarding EXIF Data

If you care about EXIF data, you cannot use TinyPNG. It does not have an option to keep the EXIF data. TinyPNG has done a lot of development over the last 1.5 years that I’ve been watching it, so that’s not to say they won’t ever support that. I think it’s a no-brainer that they should at least provide the option.

One thing you’ll hear me say several times in this post-match analysis is that when it comes to options, EWWW totally kills it. You can set it to keep EXIF or not. Set it to be lossless or lossy, add, disable, or even install different compression libraries. When it comes to EXIF data and compression EWWW is your choice, but you’ll see that the compression is not all that significant. It definitely makes a difference in those really large images, so it is still valuable.

Honestly, if page speed is really important, and EXIF data is really important to you, your best bet would be the following:

• Size your images to the exact size you want to use them at. This will make the biggest impact in getting the file size down. You can also automate that with Imsanity.
• Optimize your image in Photoshop before uploading.
• Use EWWW.
• Use a powerful CDN like MaxCDN. This will help download your images to your visitors site much quicker regardless of its size.

Regarding Your Property

As I mentioned previously, EWWW is the only option reviewed here that allows you to do all of the optimization on your hosted environment. Both TinyPNG and Kraken require that you setup an API to send your images to their servers and then download the optimized versions back to your Media Library.

This means that if you have any privacy concerns at all, then you’ll want to choose EWWW. Now, both TinyPNG and Kraken make it more than clear that they do not do claim any ownership over your images at all in their respective terms of use statements (TinyPNG’s here | Kraken’s here). Well… honestly, Kraken could be a bit more explicit about that in my opinion.

But another thing they also both make clear is that they can refuse servicing your images whenever they want. They also say clearly that they will comply with government requests for your data if asked.

For me, I’m not concerned about any of these things, and 95% of all WordPress users won’t be either. But it is a factor to keep in mind for sure.

The Actual Cost of these Plugins

Each of these “cost” something different. And truthfully, you have to think about each one in different ways:

EWWW — this might at first seem totally and unrestrictedly free. And for most people it is. But if you have a hosting environment in which you are paying for server resources directly, then you’ll have to keep that in mind. Particularly, if you use the automatically schedule optimization option EWWW has (another awesome option).

TinyPNG — You’ll see that TinyPNG provides free optimization for 500 images a month. That sounds pretty amazing, and it is. But WordPress users need to keep in mind that for every image you upload WordPress generates three more images (thumbnails, medium, large). So, immediately, this means that instead of 500 images a month you get 125 original images a month. That’s still a lot of images for most bloggers. And truthfully, the paid options are still very affordable. Plus, I like the fact that you don’t have to pay if you had a slow month.

Because of the ways I ran my test I had to watch my data useage pretty closely. While watching it, I noticed that the count didn’t always match up perfectly, but that was typically only off by 5 or 10 hits.

Also keep in mind that this image limit could be especially troublesome for you if you have a theme that has added in a bunch of new image sizes. On occassion I’ve come across themes that have added up to 5 or 7 additional image sizes. This can get pretty costly, but TinyPNG has some settings to help get around this (see “Ease of Use” below for more on that).

Kraken — This is the “priciest” of the three options. But there’s a few important caveats to keep in mind. First, they have a “micro” level that is $5/month for 500MB of images. Notice that they limit it by the data size rather than the image size. I used the $5 membership for this test which was far more than I needed in this case. And honestly, if I were to sign-up, I can’t imagine ever needing more than that.

The other thing to keep in mind is that Kraken is also more than an image optimizer. At the “Pro” level, you also get automatic Cloud Hosted backups of your images that you optimize through their Web Interface. You also get dedicated support. Personally, the option of uploading to their web interface and having the images stored there would be much more attractive if the WordPress plugin allowed you to pull those optimized images into your Media Library upon request (here’s to hoping someone on the Kraken team is reading 😉 ).

Regarding Ease of Use

The sticking point with any image optimization tool is going to be server resources. For example, a lot of hosts limit your available memory, or your image upload size, or your maximum time out in ways that can be a bit restrictive when doing some of the types of heavy processing that these tools need to do.

EWWW seemed to handle the default settings of my Cloudways environment really well. But when I first ran TinyPNG, I couldn’t finalize the Theme Unit Data import, or finish the Death to Stock uploads because I kept timing out. Luckily Cloudways has a really easy way to update that info. Once that was done everything else was smooth. But many end-users have no idea that such settings exist let alone where to find them or what to change them to. Or perhaps they are on a shared host that won’t change those settings for them at all. That could make using TinyPNG a bit problematic for some users.

As far as settings of each of these are concerned, EWWW had a dedicated settings page which is chock-full of all kinds of options. Again, most end-users might not know what to do with all that information, but it’s nice that it’s there.

Both TinyPNG and Kraken put their settings into the Media Settings page. Unfortunately, Kraken’s only settings are for inputting your API credentials. TinyPNG at least allows you to chose which images sizes you want to have automatically optimized. So if you don’t want to hit that image limit you might consider disabling optimization of the full-size image since it might never be used on your site, or perhaps you never use the 150x150px thumbnails. Whatever it might be, choosing that wisely might be a real benefit to you.

Last thing about EWWW’s abundant options: It also has settings to set a specific folder to routinely run optimizations on. This is really useful because perhaps you are a photographer and don’t want to optimize your uploads folder, but you do occasionally blog and use images that you would want to optimize. Well you could upload those to a custom folder via FTP and then they wouldn’t have multiple image sizes processed, and EWWW would optimize them on the fly. There’s other really useful settings in EWWW that I’d love to see implemented in TinyPNG since it’s optimization is so much more effective.

Wrapping it Up

Kraken optimizes on par with EWWW, but adds additional services for a premium. EWWW, though, provides the most amount of options and keeps all the processing local to your server. But neither of them come remotely close to TinyPNG’s compression performance.

TinyPNG compresses automatically far better than anything else I’ve seen available. It’s really powerful. But it’s basically an off/on kind of optimization. You’ll need to watch your usage if you want to keep it free, and you’ll lose all your EXIF data.

With all that said, considering all the different articles I’ve written on this subject, this to me is an ideal setup for any client that will have basic to moderate image usage:

1. Restrict or resize how large the images they upload are with Imsanity.
2. Optimize those images automatically with TinyPNG.
3. Make sure those images are SEO-Friendly with SEO Friendly Images (at least in a stop-gap kind of way).
4. Organize those images with Enhanced Media Library.
5. Serve up the right size image for the right size screen with RICG Responsive Images (I still need to review this in depth, so watch for a future review of this one).

Naturally, given all the caveats I gave above about privacy, EXIF data, ease of use and whatnot you might swap #2 out with EWWW or Kraken for a variety of reasons, but that’s a pretty sweet set-up.