ShortPixel – (Image) Size Does Matter
The majority of this website is related to my photography
obsession hobby. I’ve always walked a fine line on image optimization – trying to get the smallest images with the best quality and retain the EXIF/Metadata of the images. Until recently, I have been using a mix of EWWW Image Optimizer and mod_pagespeed (MPS) to compress the images and their filesize, but I wasn’t happy with the results. I did some poking around the interwebs and found a few potential contenders and tried them all out on a dev environment for this site. Ultimate, for my images, the ShortPixel plugin provided the best results and was pushed over to the production site last night.
All of the images, including NextGen galleries, have been previously compressed with EWWW, providing a modest 10% or so savings. Nothing to write home about as MPS regularly further compressed these images by about another 10%. This is important to keep in mind while reviewing the sizes achieved with ShortPixel. As a bit of a tease, here’s a screencap of the Statistics page from my ShortPixel plugin. These are pretty impressive when you think these stats are from the processing of pre-compressed images:
Here is a high level image of the request flow from the end-user to Apache using MPS to compress images in flight. The end-user’s browser requests an image (foo.gif) as part of a webpage.
MPS first validates that it is allowed to process the URL, i.e.: the file or directory has not been configured with the ModPagespeedDisallow directive. Next MPS needs to see if the file is already cached, and if the cached file has expired yet. If the file is not cached, or if it has expired, MPS processes the image to compress it based on the various image optimization directives in the web server’s pagespeed.conf file. Should the file savings meets thresholds, the compressed file is served and cached for later use. If the file is not cached and the savings do not meet the threshold, the original file is served. Finally, MPS checks if the file has been cached, apache serves the cached version of the file.
This process has saved ~10% on average for images that have been processed already using EWWW on import to WordPress‘ media library or NextGen Gallery‘s storage. While this is good and all, some of the photographs I’ve posted still are a bit hefty and various pagespeed metrics continued to complain about optimization of images. This is why I looked into other WP plugins or services to minimize image size. Speed is king 🙂
After installing the WordPress plugin and doing a quick test of a handful of images in various file types (jpg, gif and png), I plopped down a whole $9.99 (USD) for a one time purchase of 10,000 image credits. I instantly received my API Key, entered it into the plugin’s setup page and configured my optimization settings as follows:
Looking at the options, and my reasoning, I selected “Glossy” as my optimization. After running my tests, I found that this setting provided the best tradeoff between size and quality. This is a photography blog after all! Both WordPress and NextGen Gallery produce a number of thumbnails in various sizes which I included in my optimization. It is unlikely I will go through my 10,000 image credit either way, so optimize it all! Thumbnails in my not so humble opinion do not get enough love by most people.
Backups you say? I’ve recently posted about my OCD and paranoia when it comes to back up processes, so keeping an original copy of anything programmatically modified should come as no surprise to anyone reading this. Regarding image EXIF data, I decided to retain my photo’s EXIF data to maintain the Copyright info as well as camera/lens data, etc. I could have saved another couple of percent in the filesize, but it wasn’t worth the effort
Making it all play nice in the same sandbox
Prior to kicking off the bulk optimization, I spidered my site a couple of times, to “prime the pump”. I also watched the MPS file caches to make sure I was ‘pre-optimizing’ everything. Perhaps this was not necessary, but it couldn’t hurt. Once I confirmed everything was pre-cached and pre-optimized, I kicked off the bulk optimizer in ShortPixel. I watched it process and checked logs on and off for a while, then went to sleep.
Here is a flow of using ShortPixel via MPS to process images for better compression and quality.
Once the bulk job completed, I flushed my MPS caches and watched. MPS rarely found an image file to further optimize. The few it did attempt rarely provided a result that it found worthwhile saving. As an added bonus, ShortPixel also creates WebP images for browsers that support this standard, and the files are even further optimized! If you are using Chrome, you will see the WebP version of the second image automagically.
(Images moved and need to be replaced shortly)
As you can see, the degradation in quality is negligible to the human eye, and the optimization offered is amazing! For the record, these are not the image sizes typically served on the blog, but the original was used for an example of the savings possible. I could improve compression by using lossy instead of “glossy” optimizations, but this was good enough for government work 🙂
One thing I haven’t tested yet is optimizing animated GIF files, I have created a bunch of plotagraph images and blacklisted them in the plugin configuration until I get time to fully test ShortPixel’s processing of these types of images.
If you are interested, you can head over to ShortPixel and give it a try. You will not be disappointed!
pdate 2-June-2017: Using JuxtaposeJS I created the before/after image sliders for the Eiffel Tower and Sagrada Familia, seems to be working out as I wanted 🙂
Full Disclosure: I have decided to affiliate with ShortPixel – primarily because I absolutely love it, and some extra cash from referrals won’t hurt either … if you are thinking of using them, please do so through these links 🙂