The most recent release of Chrome (76) added a new “loading” attribute that supports native lazy loading in the browser. An implementation for WordPress core is still under discussion. In the meantime, plugins that enable this for WordPress sites are starting to pop up, and Google has just released one of its own.
Native Lazyload was created by Google engineer Felix Arntz and the team behind the official AMP and PWA plugins for WordPress. It lazy loads images and iframes with the new loading attribute for browsers that support it. It also includes a fallback mechanism for browsers that do not yet support it, but this can be disabled with a filter. The plugin has no settings – users simply activate it and it works.
In a post introducing the new plugin, Arntz explains why current lazy loading options, which require custom JavaScript, are not always good for performance:
Lazy-loading has for a long time not been a switch you can just toggle to make it work. It was not a browser feature, so it typically required loading and running custom JavaScript logic to make it work. Unfortunately, JavaScript itself is an expensive resource, so lazy-loading as it’s been done so far might in certain cases actually have a negative impact on performance (e.g. if a page doesn’t contain any images or only contains a single image that’s immediately visible). Furthermore, if a user had disabled JavaScript in their browsers, lazy-loading wouldn’t work at all.
The plugin uses a similar implementation that is being discussed in the core ticket. Arntz described it as a “progressive enhancement,” where a user’s website performance will “magically improve without intervention,” as more browsers add support for the loading attribute.
With the release of this plugin, and Google’s input on the related trac ticket, it’s clear that the company is interested in seeing WordPress core support the new loading attribute. Chrome Engineering Manager Addy Osmani commented on the ticket 10 days ago to lend his support for the effort and make a few recommendations.
“I’m very supportive of core getting support for native lazy-loading in a non-destructive manner,” Osmani said.
“The ideal change I would love to see in lazy-load plugins is deferring to native lazy-loading where supported and applying their fallback where it is not.” Osmani estimates that more than 17K origins are already using loading=lazy, according to Google’s telemetry.
Andy Potts, a software engineer at the BBC reported seeing major performance improvements after adopting native lazy loading. He implemented it on one of the company’s internal products, a site with approximately 3,000 active users per day:
“One of the most common actions on the site involves running a query which renders a list of up to 100 images — which I thought seemed like the ideal place to experiment with native lazy loading,” Potts said.
“Adding the loading attribute to the images decreased the load time on a fast network connection by ~50% — it went from ~1 second to < 0.5 seconds, as well as saving up to 40 requests to the server. All of those performance enhancements just from adding one attribute to a bunch of images!”
Kris Gunnars, who operates searchfacts.com, added Google’s new Native Lazyload plugin to his site and reported remarkable performance improvements, especially on mobile.
“After I installed this, my mobile PageSpeed score went from 92 to 96 and it also shaved a whopping 1.5 seconds off of my Time to Interactive score,” Gunnars said.
With WordPress powering 34.5% of the top 10 million websites, core support for native lazy loading stands to make a huge impact on the overall performance of the web. Progress on the ticket has been slow, as contributors continue discussing the best approach. In the meantime, users who are anxious to implement it on their sites can install any one of a number of plugins that are already available.
Original: wptavern.com
