From the author: read any performance blog or visit any performance talk and everyone will advise you that image optimization is the best place to start. Using automated services, you can get smaller images in a relatively short period of time. And we all know that smaller images will give us better performance – or not?
Having spent the last couple of years looking at situations where clients are looking to optimize images but then see no performance change, I decided to share a few examples of how best to deal with an issue should this happen to you.
Optimizing your photos is like buying a fast car: if you don’t have good clean roads to drive, you won’t get anywhere faster. Oftentimes, the rest of the website looks like an abandoned motorway and the extra power gain is wasted. Below are some tips on how to clean up your traffic.
Company logos and menus have been blurred to protect the privacy of these entities
On the aforementioned website, the image byte count was reduced from 1MB to 500KB (50%), but there was no performance change.
The removal of lazy loading for the main product image is a major improvement. While I can’t remember exactly what was done with the leftover images, I would always suggest checking if they are present on the screen during bootstrap, and if not, consider lazy loading, be it using JS or inline lazy loading.
We’ve also deferred one or two scripts and pre-loaded some fonts for this site, the improved results are shown below.
The results from the above image optimization project weren’t that bad:
Images reduced from 2.4 MB to 1 MB (55% smaller)
Visual performance improved by 2 seconds
However, upon first contact, the customer told us that the performance and user experience had not improved enough. From the above diagram, you can see that the main render pattern was similar before and after. A blank dark area is displayed after 2 seconds (as shown below) and then slides down when the 2 main images start loading after 3 seconds.
After looking at this site in more detail, we found that the popup menu contained hidden images on each menu tab, all loading at the top of the page with the highest priority.
Despite all of the above optimizations and some font preloading, the initial render time apparently froze somewhere around the 1.5 second mark. This client was using Optimizely which delayed rendering. Removing Optimizely reduced the time to start rendering to less than 1 second. I am not going to speculate about whether it is right or wrong to use client side A / B testing tools, this is a completely different question. I will say that if you are carefully measuring the effect of optimizing something as large as images, make sure you know all the technologies that affect the result, and then decide if you want to turn them on or off during testing.
On the surface, this site looks amazing, as the following statistics confirm:
~ 5 MB of images reduced to ~ 400 KB (92% reduction)
Full display from 7 to 4 seconds
Time to start rendering reduced by 2 seconds
Despite these improvements, the first display of the hero image remains relatively unchanged. Digging deeper, we found that the hero image was loaded as a background image, which was delaying its loading. Replacing this with the element improved the render times and made it more consistent with the below metrics.
We also found a couple of scripts that were loaded at the bottom of the markup historically meant for the last load. The browser pre-parser processed them and loaded them before the images, so we added defer.
After working through the above and other similar cases, I wondered if there were any high-level patterns that we could use to predict this issue before image optimization.
Percentage of image bytes per page
Actual image bytes
Whether the images were hosted on the same domain
Was A / B Testing Used
After evaluating sites on 16 criteria, it appears that the SpeedIndex score is likely to improve significantly if your site adheres to the following budgets:
43% or more of the page’s total objects are images
Less than 30 TCP connections (for example, not too many third-party resources)
Image optimization saves at least 50% bytes OR at least 1 MB *
* This criterion will need to be measured after image optimization, however WebPageTest shows some potential savings when analyzing all images.
If your site does not meet two or more of these criteria, I would encourage you to tackle other performance bottlenecks that need to be fixed before you start working with images.
I love to optimize images, I think this is one of the easiest aspects to optimize. However, before optimizing images, you must have realistic expectations of what you want to achieve. Optimizing performance is about more than reducing the number of bytes. There are many aspects to web page loading speed, and often removing one bottleneck will simply reveal another.
When developing an image optimization project, I recommend the following:
Be clear about how you measure impact
Select a visual metric (Speedindex, Main Content Display, etc.)
Use the right tool, WPT is good for spot checks and debugging, RUM is needed to see the impact in a real environment.
Check if you meet the criteria above, if your site does not meet these requirements, set expectations correctly
Make sure the images in the viewport load as fast as possible
Manage lazy loading properly
Use tags (including responsive images), not CSS background images
Defer any scripts to load after critical images
Think about the role of A / B testing tools during your assessment
Author: Michael gooding
A source: //calendar.perfplanet.com
Editorial staff: Webformyself team.
Bootstrap 5 framework. Quick start
Learn the basics of Bootstrap 5 with a hands-on example of coding an online store from scratch!