Lazy loading is a common software design pattern that defers the initialization of objects until they are needed. Lazy loading images started to become popular on the web back in 2007, when Mika Tuupola drew inspiration from the YUI ImageLoader utility and released a jQuery plugin. Since then, it’s become a popular technique to optimize page loading and the user experience. In this article I will discuss why we should and shouldn’t use Lazy Load, and how to implement it.
Why Lazy Load?
Images make up over 60% of an average page’s size, according to HTTP Archive. Images on a web page would be rendered once they are available. Without lazy loading, this could lead to a lot of data traffic that is not immediately necessary (such as images outside of the viewport) and longer waiting times. The problem? Visitors are not patient at all. By lazy loading, images outside of the viewport are loaded only when they would be visible to the user, thus saving valuable data and time.
Why Not Lazy Load?
Lazy loading is not a silver bullet, and it is known to affect performance. For example, most lazy-loading implementations either don’t have a
src attribute in the
tags (which is invalid syntax, according to the HTML5 standard) or point to a blank image (hello,
spacer.gif). This approach requires duplicate
tags wrapped in
Fortunately, this duplication doesn’t increase the page’s size significantly when you enable Gzip compression. However, some search engines might not index your images correctly, because the
tag is not indexed within content, and the
tag outside of
is referring to a blank image. Currently, Google seems to eventually index lazy-loaded images, but other search engines are less likely to.
How Is Lazy Loading Implemented?
You might be overwhelmed by the number of lazy-load plugins out there. You might also think that implementing one is easy: Just monitor page scrolling (or resizing), and then set the
src attribute when an image is visible. If only it were that easy. Many things come into play when building a solid solution that works on both desktop and mobile. So, how do you separate the signal from the noise?
Checking the visibility of images after every interaction (even a tiny bit of scrolling) could compromise the page’s responsiveness. To ease that, implement some sort of throttling mechanism.
- All your mobile are belong to us
There is no
scrollevent in the Opera Mini browser and some old feature phones. If you receive traffic from those devices, you should monitor and load all images directly.
- Lazy load or automatic pagination?
Some implementations check only whether an image is above the fold. If the page is scrolled down to the very bottom via an anchor (or the
- Dynamic image insertion
Many websites use AJAX navigation nowadays. This requires a lazy-load plugin to support the dynamic insertion of images. To prevent a memory leak, any references to images that are not in the DOM (for example, ones that appear after an AJAX-based replacement of content) should also be removed automatically.
This list is certainly not comprehensive. We have many more issues to consider, such as the lack of
getBoundingClientRect in old browsers, a change in orientation without an ensuing
resize event on the iPhone, or the particular handling requirements of the jQuery Mobile framework.
Unfortunately, most plugins do not handle all of the above.