Felix Arntz 7:45 pm on January 29, 2020
Tags: feature-lazyloading ( 8 )

Lazy-Loading Images in WordPress Core

Lazy-loading images has been a commonly used mechanism to significantly improve pageload performance for several years. For the WordPress ecosystem alone, there are a myriad of plugins that enable lazy-loading.

While historically lazy-loading images has required a custom JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.-based approach, there is now a native web solution which relies solely on the presence of a new loading attribute on img tags and provides a standardized user experience without content shifting. The HTML specification for the loading attribute is near completion and is already supported by several browsers, including Chrome and Edge.

Enabling lazy-loading for images in WordPress content was first proposed nearly two years ago, however the JavaScript implementation at the time would potentially have introduced many edge cases and failures. Using the new loading attribute removes these concerns. This post describes the suggested solution.

Performance Impact

According to HTTPArchive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send about 4.7 MB of images on desktop and mobile.
Native lazy-loading for the web, web.dev

Without lazy-loading, all images on a web page are loaded immediately. This can significantly harm performance, especially on pages that contain many images. If several of these images are “below the fold”, i.e. the part of the page that the user does not immediately see, loading those images right away is unnecessary and potentially even wasteful of networknetwork (versus site, blog) resources: If the user never scrolls towards those images, they would have been loaded regardless.

Since lazy-loading has become a must-have performance improvement, the new loading attribute specification aims to standardize the behavior and make it even faster, integrated in the web platform.

With WordPress enabling native lazy-loading by default, it would significantly impact performance and user experience for millions of sites, without requiring any technical knowledge or even awareness of lazy-loading as a concept. Adopting the new loading attribute is a great chance for WordPress to lead the way for a faster web overall.

Technical Solution

The loading attribute currently supports two possible values:

eager, to load an image immediately on pageload
lazy, to load an image only when it becomes relevant for the viewport

The implementation seeks to enable lazy-loading images by default, providing the loading attribute with value lazy on the following img tags:

Images in post content
Images in post excerpts
Images in comments
Images in text widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. content
Individual images rendered via wp_get_attachment_image()
AvatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. images rendered via get_avatar()

Note that loading="lazy" will only be added if the respective tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) does not yet include a loading attribute. In other words, to prevent an image from being lazy-loaded, it is recommended to specify loading="eager".

Customization for Developers

Note that the customization capabilities outlined below and how they work exactly is subject to change.

While the images outlined above will be lazy-loaded by default, developers will be able to override this behavior both globally and on a per-image basis.

A new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. wp_lazy_loading_enabled will allow turning the feature on and off. For example, one could disable lazy-loading entirely with the following snippet:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

This filter also passes a secondary parameter $tag_name, which is a specific tag name to enable or disable lazy-loading for, and $context, which typically is the name of the current filter being run. Currently, img is the only supported value, but since adding loading support to additional tags is on the horizon (e.g. some browsers already support the loading attribute on iframe tags), this parameter exists for future compatibility. For example, if you want to be more specific and disable lazy-loading only for images (so that future supported tags would by default have it enabled), you could use the following snippet:

add_filter(
	'wp_lazy_loading_enabled',
	function( $result, $tag_name ) {
		if ( 'img' === $tag_name ) {
			return false;
		}
		return $result;
	},
	10,
	2
);

In addition to this filter which allows customization across the entire site, there is another filter wp_img_tag_add_loading_attr that filters the value of the loading attribute for individual control per image. The filter passes the full img tag markup including all attributes as second parameter, and the context, which typically is the current filter being run. wp_img_tag_add_loading_attr can for example be used for interoperability by plugins that currently use alternative mechanisms to lazy-load, for example a class or a data attribute. It is recommended to only do this as a transition though, and in the long run update such plugins to specify loading="eager", in which case coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will leave that in place as is, as mentioned before.

Please see the inline documentation in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for more detail on how to customize lazy-loading behavior.

Call for Testing

The proposed solution is available as a feature plugin WP Lazy Loading in the plugin repository. The plugin is being developed on GitHub. Your testing and feedback will be much appreciated. Particularly testing interoperability with various content creation mechanisms (e.g. blocks, shortcodes) and existing lazy-loading plugins would be helpful. The current goal is to get this feature released as part of WordPress 5.4, merging in the next two weeks.

Please share your ideas, questions and thoughts either in a comment on this post, in the plugin’s support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations. on wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, or on the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository.

#feature-lazyloading

Anonymous User 7:54 pm on January 29, 2020

This is Awesome! (sorry for the relatively useless comment, just wanted to say as thanks)
John Blackbourn 8:17 pm on January 29, 2020

A question was raised in #44427 about enabling lazy loading by default for all images, and why Chrome doesn’t just do this without bothering with the `lazy` attribute at all.

I’m wondering why doesn’t Chrome do this already, if it’s safe, and what makes it different for WordPress

Did this get discussed or answered anywhere?
- Andrew Ozz 12:10 am on January 30, 2020
  
  Yes, ideally the browsers should load all images “lazily” by default. My initial understanding was that the auto value would eventually mean “lazy if possible” and the loading method would perhaps depend on some more conditions like hawing width and height attributes. However auto was dropped from the specs.
  
  It’s true that WordPress “pushes the edge” here by planning to add lazy-loading to most images by default, retroactively. The main reason the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. was made is to allow as wide testing as possible. The attributes are also added in a way that can easily be changed or removed, if the browsers start to load images lazily by default.
- Houssein Djirdeh 10:06 pm on February 9, 2020
  
  Note: I work on the Chrome Speed team and worked on developer messaging around the loading attribute.
  
  We’ve rolled out “opt-out” behavior where all offscreen images are lazy-loaded by default for Chrome Android users with Lite Mode enabled. We may explore more opportunities to enable default lazy-loading in the future for more than just Lite Mode users, but there are no plans as of yet.
Weston Ruter 1:45 am on January 30, 2020

Should images by default only be automatically lazy-loaded if they are coming from wp-content/uploads? That could help avoid unintentional laziness since images in uploads would exclusively be static. Images being loaded from other sources could have some reason for not being lazy-loaded, like if they are for tracking pixels or something. Sure the workaround could be to just explicitly add loading=eager, but that would require updating existing content. I don’t feel strongly about this but I just wanted to make sure it was considered.
Arunas Liuiza 8:42 am on January 30, 2020

I am happy to see that some kind of lazy-loading is coming to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. It is a good feature to have. I’m just not that sure about the timing of this. Despite the nice wording around it in the post, this is not yet part of WHATWG specification and only one rendering engine actually supports it. So this seems like a bit of putting the wagon before the horse. And maybe using the weight of WordPress to push through a feature that has not seen a wide adoption among browser vendors, yet. From what I am seeing here: https://bugzilla.mozilla.org/show_bug.cgi?id=1542784, Firefox is nowhere near supporting this yet.
Hendrik Luehrsen 9:29 am on January 30, 2020

Thank you for this proposal! Image loading is a very hot topic and rolling this out would certainly bring a faster web to a lot of people.

BUT, I have my issues with this approach. The `loading` attribute is a self defined Google/Blink standard, currently not supported by the W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. spec or any browser not using Blink. This feels like we are going back to the ‘Optimized for …’-days in web development.

What worries me is that this has the potential to create unforseen consequences for how standards are being set in HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. Rolling this into WordPress would make the `loading` attribute the de-facto standard for this purpose, without a chance from other browser vendors or the W3C to consent or give feedback.

To play the devils advocate here: Theoretically any corporation with a large enough open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. group could take this route to circumvent the standard specification route and define de-facto standards which are in their own self interest.
Sander 11:07 am on January 30, 2020

Hey. I have a few concerns related to timing of landing this.

Is it a good idea to speculatively implement a draft spec that is currently supported by one browser engine soon? It is putting pressure on browser makers to implement a spec subject to change and then support that until the end of times preventing the finished spec from getting supported. We have seen this in the past browser wars.

It also sets expectations on site owners that modern browsers support it, especially if marketed as “WP now supports lazyload”.

Finally it doesn’t sit with WP vision for supporting the open web to push chrome features.

These concerns are all timing related, and don’t take away from the idea and development of this feature.
- Houssein Djirdeh 10:48 pm on February 9, 2020
  
  Disclaimer: I work on the Chrome speed team 🙂
  
  The spec PR looks pretty stable with only minor changes expected to land. I understand that there’s a deadline that needs to be met for features to be merged in before the next WP release, but I also agree that it could be quite contentious to have this merged in before the feature becomes an official WHATWG standard.
  
  If this feature gets merged sooner rather than later due to time constraints, I think the correct course of action would be to remove it entirely if the spec PR does not get merged in time for the next release.
  
  CC @flixos90
Andrea Fercia 4:01 pm on January 30, 2020

is already supported by several browsers

“Several”? 🙂Basically one. At the time of writing this, the other ones have a global usage percentage under 0.1%. Also, the spec is not merged nor finalized yet.
Michael Nelson 6:44 pm on January 30, 2020

Native lazy loading does sound great. My concerns are:
1. This seems quite rushed. 2 weeks of it being a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. doesn’t sound like enough time for adequate testing before merging it into a 5.4 (it currently reports fewer than 10 active installs)
2. This feels a bit like Google strong arming other browsers into adopting their standard (as it isn’t yet a WHATWG standard, certainly not a W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. standard)

I’d be all for it once the spec is approved by WHATWG and the feature plugin has more active installs.
- thaikolja 2:38 am on January 31, 2020
  
  I skimmed over the main (and only) .php file of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and couldn’t find any mechanism that actually lazy-loads images. I think as the title of the plugin already says, it’s only a…
  
  …Feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. for testing and experimenting with the “loading” HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attribute.
  - Michael Nelson 12:08 am on February 1, 2020
    
    Right it adds an HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attribute onto images. Chrome and Edge then use that to perform the lazy loading. (Other browsers won’t.) It doesn’t do the lazy loading directly.
    Folks should check Chrome and Edge’s behavior with these news tags doesn’t affect their site’s layout etc.
thedevbear 8:06 pm on February 4, 2020

thank god for the filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. allowing us to turn this off. Please do the same for the XML feature.
Joe McGill 4:16 pm on February 6, 2020

I’m definitely in support of automatically shipping these types of HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. based performance improvements in WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and am happy to see that this implementation adds the `loading` attribute during rendering, rather than saving this markup to the database, since it’s still not an official part of the HTML standard.

In terms of timing, I’d like to see the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. in use on more sites to allow for more feedback before this gets included in WordPress Core. I think WP 5.5 would be a better target now that we’re only a few days away from the first betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. release for WP 5.4.

For implementation, I’m curious if you have considered introducing this behind a `theme_supports` flag, rather than making this the default behavior for every site that upgrades to whatever version of WP this is added to?
- Weston Ruter 4:22 pm on February 6, 2020
  
  I’m definitely in support of automatically shipping these types of HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. based performance improvements in WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and am happy to see that this implementation adds the `loading` attribute during rendering, rather than saving this markup to the database, since it’s still not an official part of the HTML standard.
  
  Question: Were srcset and sizes part of a standard when they were merged? Or did they become a standard because they were deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. en masse in WordPress? (Chicken and egg.) I only have fuzzy memories of RICG.
  - Joe McGill 4:35 pm on February 6, 2020
    
    Yes, they were already a standard when we added responsive images. We also had several months of people using the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and leaving feedback before we merged it.
    
    We did see a large bump in usage across the web platform after the release, however, so these types of efforts in WP are really useful!
Weston Ruter 3:30 pm on February 10, 2020

For Firefox, this just popped up:

In Firefox 75, I intend to turn lazy load images on by default.

See Intent to prototype and ship: lazy load images.
Francesca Marano 12:42 pm on February 11, 2020

Hello folks! How are we doing with the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party? We are ready to start BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 today at 8PM UTC
Thank you
Weston Ruter 3:11 pm on February 12, 2020

And pull request merged to add loading=lazy to whatwg/htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.!
Andrea Fercia 9:40 am on February 13, 2020

Correct: the “loading” attribute was merged into the WHATWG HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Living Standard `whatwg:master` a few hours ago (February 20, 2020) which is 22 days after this post was published: https://github.com/whatwg/html/pull/3752#issuecomment-585202516

Still not a W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. recommendation though, even if the difference is very subtle. Regardless, what really matters here is browsers support.

WordPress 5.4 is in BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 now and I share the concern merging this new feature in 5.4 would be quite rushed. For clarity: I think everybody agrees the new “loading” attribute is awesome. The concern is only about timing.

At the time of writing this, basically only Chrome, Edge, and Opera support the “loading” attribute. Edge and Opera have a very low usage percentage, which leaves us with only Chrome. Right now, Firefox, Safari, and several mobile browser don’t have any support for the “loading” attribute.

As I see it, an open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project should never favor only one browser over all the other ones. Merging this new feature in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. would give de facto a clear advantage to Google Chrome against its competitors. I don’t think WordPress should do this.

I’m assuming good intent but, as I previously commented, I find the sentence at the beginning of this post misleading and basically incorrect:
is already supported by several browsers, including Chrome and Edge.

Stating that “several” browsers support this feature isn’t correct.

I would have appreciated some more transparency, including a disclaimer at the very beginning of this post to let the larger audience reading this post know what is the organization some of the persons who are proposing this feature work for.

I’d like to kindly suggest to reconsider this proposal when all the major browsers including the mobile ones (where lazy loading is even more important) will support the new attribute. That is likely going to happen in time for WordPress 5.5.
- Daniele Scasciafratte 9:54 am on February 13, 2020
  
  I agree with Andrea, if the role of WordPress is Democratize the experience on the web… well this implementation it isn’t.
  As a lot of people say when someone suggests a feature in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. but is not in the WP scope: There is a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for that.
  
  Honestly there are other feature requests (or bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixing) that require more interests and moving on for me.
Andrea Fercia 10:37 am on February 14, 2020

Update: the loading attribute is now enabled by default in Firefox (merged a few minutes ago). To my understanding, it’s planned to be released with Firefox 75 (planned for April 2020). See https://bugzilla.mozilla.org/show_bug.cgi?id=1613611

No news about Webkit and other browsers.
- andronocean 4:36 pm on February 17, 2020
  
  Appears that Webkit was waiting for WHATWG to publish the spec, and work on getting this implemented has now resumed.
Saumya Majumder 3:01 pm on April 7, 2020

Any eta on when this is getting added in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP?
- Luke Cavanagh 9:12 pm on April 18, 2020
  
  Looks like it is on track for the WordPress 5.5 upcoming release.
  https://make.wordpress.org/core/2020/04/08/lazy-loading-of-images-is-in-core/
  - Saumya Majumder 7:04 am on May 5, 2020
    
    That’s awesome. Thanks a lot for sharing the link. 🙂
altoscameron 3:40 pm on May 7, 2020

will the rest apiREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. responses include this attribute as well?