Pagespeed Says My Images Need More Work

So, you’ve run the EWWW Image Optimizer on all your images (or another IO plugin) and  Pagespeed Insights (or GTMetrix, or Yslow, etc.) still says you need to do more with your images? What do you do next?

PageSpeed Insights (PSI) Moves to Lossy Compression

First of all, you need to be aware of one very important thing with PageSpeed Insights (PSI): it uses lossy compression instead of lossless. That means PSI has reduced the quality of your images in order to achieve the results they are recommending. Instead of lossless compression, PSI now uses the freely available ImageMagick utility at quality 85 to compress images. I've written a  very long, and detailed explanation of what that change means for you. In short, it means that if you want to meet or exceed the PSI recommendations, you should use the Max Lossy setting in EWWW IO, and ignore any compression recommendations PSI makes when/if you retest your page. You should certainly expect to see fewer images listed, because EWWW IO out-performs PSI by 10% on average. However, since PSI uses lossy compression, and the compression methods of EWWW IO and PSI are vastly different, the PSI results on re-testing will not be 100% accurate. 

For example, a page we tested recently showed that a particular image should be 113kb, so we ran EWWW IO on the highest settings, and got it down to 105kb, with less quality loss. When we ran PSI to confirm the changes, it said we should compress it another 5kb. We had already exceeded their recommendation by 8kb, and now they wanted more... Does it make sense to compress it one more time? That's a big, huge "NO".

A short analogy can help to understand the difference between PSI compression, and EWWW IO's methods. 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. If you then 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. Read more on The Chisel Versus the Chainsaw.

Yes, Max Lossy requires an  API key, but you still have a choice to make here. Is lossy compression right for your site, or do you need pixel perfect optimization? For most sites, lossy compression will be a nice boost to your speed, and the quality loss is less than noticeable. If you don't make money with your site, or you need pixel-perfection, then stick with lossless compression. You'll still get a faster site, even if the change isn't as dramatic. If you decide to stay with lossless compression, GTmetrix.com is a good site for testing your results, as they still use lossless compression in their tests (as of ).

Images from your Media Library can be reduced by lossless compression

You won't see this on PageSpeed anymore, but  GTmetrix still uses this recommendation. If you already optimized your images once, the most likely culprit is image metadata. To fix this, make sure you enable the ‘Remove metadata’ option in EWWW I.O. All the page testing tools expect metadata to be stripped. This will not have a negative impact on SEO, search engines don’t care about metadata, because normal people can’t see it anyway. It is much more important to make sure you have ‘alt’ and ‘title’ tags on your images. The metadata we’re talking about is excess data embedded in the actual image file itself. This is different than the WordPress metadata stored in the database which contains information about available resizes, mime-type, as well as a copy of some of the useful information from the actual image metadata.

Images somewhere else can be reduced by (lossless) compression

If Pagespeed is flagging images that are not part of your Media Library, such as on-demand resources created by another plugin/theme, you can add the full path to the folder where the images are stored to the EWWW I.O. Settings. The “Folders to Optimize” setting is on the advanced tab, and requires the absolute path, not the path relative to your WordPress install. The auto-detected path to your WordPress install is listed directly above this setting for your reference. If it doesn’t save the setting, then you didn’t enter the path correctly. If you need help with that,  contact us.
Once you’ve saved the extra Folders to Optimize, you should visit the Bulk Optimize page under Media Library, and run a Scan & Optimize. Once that has completed, you can turn on the Scheduled Optimization setting. However, you should only enable Scheduled Optimization if new images in the Folders to Optimize are not being optimized on creation. You can view all the images the plugin has optimized on the Bulk Optimize page, by clicking Show Optimized Images. This will help you to verify if the new images are being optimized automatically or not. And of course, if you still are not sure whether those images are being auto-optimized,  give us a holler.

Images need compressing and resizing

This basically means your images are too large for where they are being displayed. It is also one of the harder problems to fix. The first thing you need to determine is what sizes are needed. For this, I use the Firebug plugin for Firefox, or the built-in developer tools for Google Chrome. Find the image that is causing the image in your page, right-click, and then Inspect Element. Then you will need to look at the height and width attributes to determine at what size the browser is displaying the image. There are some images that will be displayed by javascript, and it can be difficult to find the actual size. If you hover over the actual image filename in either Firebug or Chrome’s Developer Console, you will see the dimensions displayed.
Once you know how large the browser thinks the image should be, you need to find a way to make your images the right size. If these are images from your Media Library, you may be able to fix them with the Simple Image Sizes plugin. This lets you generated the appropriate resized versions for plugins (or your theme) to display on your pages. Another solution is the Adaptive Images plugin. It will run when your page loads and generate several resized images on demand. It also caches them to disk so that it isn’t slowing things down on every page load.

Webpagetest.org

This site recommends using lossy compression at level 50. My gut reaction to that is ewww (pun intended). Level 50 is going to look like crap, unless you’re half-blind. The good news is that you can have the best of both worlds. You can achieve dramatic results (often beating the claims at WPT), and retain visual clarity by using the lossy JPG setting in EWWW I.O. We use the incredible TinyJPG (Max Lossy) and JPEGmini (regular lossy) technologies to achieve these results, and you can test it out for yourself with some sample images at tinyjpg.com or jpegmini.com if you are hesitant to make the switch.

Still need help? Contact Us Contact Us