The answer is: if you care about mobile performance and payload, then you need a better solution than only 3 image sizes. We evaluated over 53 million requests for images from 1.6 million distinct urls (see our MOVR report). On average, it takes only 8 requests to surpass the need for 3 image sizes. Resizing to the standard 3 versions helps reduce the payload to 63% of the original. But if you automatically detect the actual device, resize, and compress to an optimal size, then you can save 84% of the payload. For image-heavy sites with a large amount of mobile users, this performance improvement could have a big impact on user experience and e-commerce conversions, potentially generating millions of dollars.
Replacing lazy-loading with the new Responsive Images specification will address the pre-loading issue, but the risk of downloading an over-sized version of the image is just as significant.
How serious is the image breakpoint problem? Or asked differently, how many different versions do you need to achieve more savings? Over time, the number of image requests increases the variety of devices visiting your sites. Based on our research data on serving images to thousands of sites, it takes only 8 requests to surpass 3 image-size versions. At 180 requests, you surpass 11 image-size versions. At 1,000 image requests, you surpass 20 image-size versions.
Now that we know the number of image-size versions to expect, what does optimizing for these variations yield? Can you actually save payload?
If you “roughly” resize for the standard 3 dimensions, your payload over will be 63% versus delivering a single image. Not too bad. But if you 1) automatically detect the device, OS, browser, 2) resize to exact dimensions and pixel ratio, and 3) compress and render in the most efficient file format, then savings is more: only 16% of the original payload.
RWD is here to stay, but the convention of lazy-loading 3 image sizes needs to change. It sacrifices too much web performance. However, even if you set up 20 breakpoints and image versions, these breakpoints will change over time. New devices and form factors arrive, and older devices drop out. Even if you wanted to take on the task of resizing 20 versions for every image on your site, maintaining it would be a major headache. And aren’t there more strategic uses of your time?
Data: We collected image request data from 1.6 million distinct urls using the ImageEngine service over a 4 month time period. We collected 53.5 million image requests coming from a variety of devices.
Image size versions: Our WURFL device detection can identify the device requesting the image. WURFL provides a number of WURFL device capabilities – including dimension and resolution, OS, and browser. Based on WURFL capabilities, we can determine whether a new image version is required for a device, or whether an existing image version suffices.
The actual number of requests for an image various based on traffic visiting the site. The curve shown above represents an equation that statistically best fits the image request and image-size version data we have collected.
Payload savings: The ImageEngine service records the size of the original image. Therefore, we can extrapolate the Original payload size by multiplying the original file size times the number of requests.
For the 3 Versions, we simulated the impact of using 3 versions: desktop, tablet, and smartphone. Desktop had a width of 1024 pixels. Tablet corresponded to the iPad with a width of 768 pixels. Smartphone had a width of 375 pixels based on the the Apple iPhone 6S.
For the Multiple Versions, we have actual results of the payload delivered from the ImageEngine service when images are resized and compressed for the capabilities of a specific device.