Optimizing your images is often the very first suggestion that any performance writer or consultant will make when it comes to optimizing a website. We’re no exception. Make no mistake, this is a key step to take and should absolutely be a part of your web design/development routine. However, what do you do when you optimize your images and still don’t see a noticeable improvement in the performance of your site?

Michael Gooding (@Michael_G_81) takes a look at this, as it’s one of the more frustrating experiences in web performance. His article in the Web Performance Calendar, The ugly truth about optimizing beautiful images, explores a few case studies and offers some solutions as well. If you’re not seeing the results you expected after optimizing your images, check out these suggestions.

Images are being lazy-loaded above the fold

If you’re a frequent reader of our blog, you know we love lazy-loading images. Lazy loading means that the image isn’t loaded until the user scrolls down the page and that image comes into few. This is great for performance because if the user doesn’t end up scrolling down that far, the image doesn’t load at all, shaving valuable time from our loading metrics.

In the above article, we walk you through how to implement lazy loading for your images in 83 seconds! However, when we implement lazy loading, we don’t want to add it to any images that are on the screen right away. Why? Because these above-the-fold images are immediately on the screen, so there’s no point in adding lazy loading to these. It may also make these images, and ultimately your site, appear to load slower.

If you’re using a WordPress plugin to implement lazy loading, it will often make this distinction for you. However, if you’re implementing this yourself, I would advise you to check and see if the image is on the screen during the initial load. If not, add lazy loading via a Javascript library, WordPress plugin, or via native lazy loading.

Plugins may be congesting your site

One really useful way to view how your website loads is through the ‘filmstrip’ feature. This allows you to see metrics such as First Contentful Paint, frame by frame. Most performance audit services offer this view, and it can be great for comparing your site pre and post optimization.

Case 2 in Gooding’s article, was an instance where the total size of the site’s images was cut in half, visitors were still experiencing lag. By checking out the site’s filmstrip on the site speed audit, he saw that the ‘start render’ time was stuck at 1.5 seconds. After looking through the site’s plugins, it turned out that an A/B testing plugin was delaying the render. One this block was removed, there was a huge improvement.

This illustrates exactly why we at MachMetrics suggest using continuous monitoring of your site. Had this been implemented in this instance, the site owner would see exactly how that A/B testing plug had negatively affected site performance as soon as it was installed.

Javascript is blocking the render

In the final case study in Michael’s article, the total image size was reduced by 95%. Those must have been some huge images! Unfortunately, the site was still taking a long time to start rendering. Upon a deeper review of the code, it was found that scripts which were supposed to be loaded last, were being pulled up by the browser and loaded first. This was blocking everything else from rendering.

If you’ve ever audited your site with Google Pagespeed Insights tool, you’ve likely seen this warning:

Pagespeed Insights will usually tell you which scripts are blocking the render. You can also check out a waterfall chart of your site loading such as the example below. If you see a script that is loading while everything else waits, that is a good place to start.

By adding defer to these scripts, you can stop them from blocking everything else that needs to load. There are many WordPress caching/speed optimization plugins that will also do this for you as well. One of our favorites, WPRocket, makes it as simple as flipping a switch in the settings area.

Further analysis

One of the most interesting aspects of this article was where Michael dug deep into the patterns that might alert a website owner that images aren’t their biggest problem.

After scoring the sites against 16 criteria it turned out it is more likely to see significant improvement in SpeedIndex if your site adheres to the following budgets: – 43% or more of total page objects are images – Less than 30 TCP connections (e.g. not too many 3rd parties) – Less than 400KB of JavaScript (on the wire) – JavaScript less than 45% of image bytes – After optimizing images, save at least 50% of bytes OR at least 1MB * Michael Gooding (@Michael_G_81)

If your site fails 2 or more of those criteria, then it likely has other congestion issues that need to be addressed.

Summary

To be clear, we love optimizing images. Optimizing your images remains the easiest way to see a marked improvement across your speed performance metrics. However, since it is so universally recommended, some users expect it to automatically take care of all speed issues. Good performance is a process, and is more than reducing size.

The good news is that you now know some common areas where additional bottlenecks can occur. This is half the battle. Armed with this information, you can address the real congestion and get the performance you were hoping for.

In addition to optimizing your images, make sure you are also doing the following:

Defer scripts that are blocking rendering

Don’t apply lazy loading to images that are above the fold

Consider the plugins/libraries you are using and their effects on performance

Most importantly, use a speed monitoring service that monitors at regular intervals. You’ll be better informed about the overall health of your website!