Earlier this month, Google Chrome 76 got native support for lazy loading. Web developers can now use the new ‘loading’ attribute to lazy-load resources without having to rely on a third-party library or writing a custom lazy-loading code.
Why native lazy loading is introduced
Lazy loading aims to provide better web performance in terms of both speed and consumption of data. Generally, images are the most requested resources on any website. Some web pages end up using a lot of data to load images that are out of the viewport. Though this might not have much effect on a WiFi user, this could surely end up consuming a lot of cellular data.
Not only images, but out-of-viewport embedded iframes can also consume a lot of data and contribute to slow page speed. Lazy loading addresses this problem by deferring the non-critical, below-the-fold images and iframe loads until the user scrolls closer to them. This results in faster web page loading, minimized bandwidth for users, and reduced memory usage.
Previously, there were a few ways to defer the loading of images and iframes that were out of the viewport. You could use the Intersection Observer API or the ‘data-src’ attribute on the ‘img’ tag. Many developers also built third-party libraries to provide abstractions that are even easier to use. Bringing native support, however, eliminates the need for an external library. It also ensures that the deferred loading of images and iframes still work even if JavaScript is disabled on the client.
How you can use lazy loading
Without this feature, Chrome already loads images at different priorities depending on their location with respect to the device viewport. This new ‘loading’ attribute, however, allows developers to completely defer the loading of images and iframes until the user scrolls near them.
The distance-from-viewport threshold is not fixed and depends on the type of resources being fetched, whether Lite mode is enabled, and the effective connection type. There are default values assigned for effective connection type in the Chromium source code that might change in a future release. Also, since the images are lazy-loaded, there are chances of content reflow. To prevent this, developers are advised to set width and height for the images.
You can assign any one of the following three values to the ‘loading’ attribute:
- ‘auto’: This represents the default behavior of the browser and is equivalent to not including the attribute.
- ‘lazy’: This will defer the loading of the images and iframes until it reaches a calculated distance from the viewport.
- ‘eager’: This will load the resource immediately.
Support for native lazy loading in Chrome 76 got mixed reactions from users. A user commented on Hacker News, “I’m happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn’t account for this accessibility.”
Another user expressed that it does hinder user experience. They commented, “I may be the odd one out here, but I hate lazy loading. I get why it’s a big thing on cellular connections, but I do most of my browsing on WIFI. With lazy loading, I’ll frequently be reading an article, reach an image that hasn’t loaded in yet, and have to wait for it, even though I’ve been reading for several minutes. Sometimes I also have to refind my place as the whole darn page reflows.
I wish there was a middle ground… detect I’m on WIFI and go ahead and load in the lazy stuff after the above the fold stuff.”
Right now, Chrome is the only browser to support native lazy loading. However, other browsers may follow the suit considering Firefox has an open bug for implementing lazy loading and Edge is based on Chromium.
Read Next
Why should your e-commerce site opt for Headless Magento 2?
Angular 8.0 releases with major updates to framework, Angular Material, and the CLI
