You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Optimization Detective: Implement lazy-loading of background images #1035
At the WordCamp Asia Contributor Day, @shilo-ey shared a very interesting thing that Elementor is doing to optimize the loading of background images by lazy-loading them. Background images cannot be lazy-loaded using loading=lazy like regular images can since they are CSS and not img elements. So Elementor is using a clever approach to force all background images to be hidden after the first N with a style rule. Then it uses IntersectionObserver to remove the style rule once scrolling.
This could be done with Optimization Detective as well, but in a more accurate way since it wouldn't have to assume to not lazy-load the first N images and it can instead use the elements in the URL metrics to know which background images are actually in the initial viewport, and only exclude them from lazy-loading.
When JavaScript is turned off, the lazy-loading of the background image should ideally be disabled. This can be achieved by wrapping the CSS rules to disable the background images outside the initial viewport with the scripting media query:
I'd like to provide an update to this thread since my exploration has progressed significantly since that initial gist!
My aim was to:
Implement lazy loading for backgrounds, videos, and all other elements requiring lazy loading within the page.
Achieve this without the need for any custom or special markup. Hence, approaches such as using CSS backgrounds or data-lazy attributes are not considered viable solutions.
Detect the position of elements within the viewport and prevent lazy loading on those items.
You can find the repository here along with the IIFE script (just in case you'd like to test it with your sources 😉).
If you'd like to give it a try, I've prepared some pages for testing with different scenarios:
In my tests, the pages are only slightly slower (by 100ms) compared to native lazyload. However, since native lazyload requires custom markup, auto-lazyload should provide an immediate reduction in page load time without the need to make any changes (and revert changes when you no longer want to use this plugin), especially for platforms like WordPress where there are elements such as covers with backgrounds, videos without posters, etc. This immediate improvement in load time can be significant.
Feel free to explore and test these pages! Let me know if you have any questions or feedback.
Another metric that i can provide to show how this plugin act on a real website, is the Wordpress.org homepage waterfall. I use the local override to overrideride the html file and inject the autolazyload script at the beginning of the body, the result is 11sec vs 17sec, not bad 🎉
Note that this would need to be limited to background images which are defined inline via style attributes, at least to start.
Background images which are defined in external CSS files are more difficult to handle. I'm working on prioritizing the loading of such externally-defined background images in #1584, but it may not be feasible to lazy-load them. This is because the detection logic doesn't know up-front which elements have background images, so it doesn't know which to attach data-od-xpath attributes for. For the LCP element with a background image at least, we might be able to figure out which element detected client-side corresponds with a tag when iterating over the document during optimization through some heuristics, especially if the element has an ID.
In any case, I expect that most non-inline background images are going to be used in the page header and so won't need to be lazy-loaded anyway.
Activity
westonruter commentedon Mar 25, 2024
See also this implementation that @erikyo just shared (see Slack thread): https://gist.github.com/erikyo/8e38a9bdeddfc3fea315399c0107ff09
Nevertheless, we need to be careful not to lazy-load a background image that is in the initial viewport.
erikyo commentedon Apr 5, 2024
I'd like to provide an update to this thread since my exploration has progressed significantly since that initial gist!
My aim was to:
You can find the repository here along with the IIFE script (just in case you'd like to test it with your sources 😉).
If you'd like to give it a try, I've prepared some pages for testing with different scenarios:
In my tests, the pages are only slightly slower (by 100ms) compared to native lazyload. However, since native lazyload requires custom markup, auto-lazyload should provide an immediate reduction in page load time without the need to make any changes (and revert changes when you no longer want to use this plugin), especially for platforms like WordPress where there are elements such as covers with backgrounds, videos without posters, etc. This immediate improvement in load time can be significant.
Feel free to explore and test these pages! Let me know if you have any questions or feedback.
erikyo commentedon Apr 5, 2024
Another metric that i can provide to show how this plugin act on a real website, is the Wordpress.org homepage waterfall. I use the local override to overrideride the html file and inject the autolazyload script at the beginning of the body, the result is 11sec vs 17sec, not bad 🎉
Auto-Lazyload

Current Wordpress website performance

rcwd commentedon May 14, 2024
Hello, i tried your js class and it is working well.
I have found an issue with background images added via js, i have this scenario:
<div id="mybgimage">.....</div>What happens? By checking the Chrome console, all 4 bg images are downloaded in network tab.
Is there a way to fix this?
Thanks
erikyo commentedon May 14, 2024
@rcwd thank you for testing! can you please file an issue here? 👉 the autolazyload repo
rcwd commentedon May 14, 2024
@erikyo thanks! Issue opened.
rcwd commentedon May 14, 2024
Hello again @erikyo, is there a way to exclude some images to be lazyloaded?
erikyo commentedon May 14, 2024
@rcwd please refer to my GH repository, don't post here because unrelated
short answer: at the moment no, but if you kindly can file a new issue I will try to solve it! 😇
ShyamGadde commentedon Nov 21, 2024
Hi, could this issue be assigned to me? I'd like to work on it. Thanks!
westonruter commentedon Nov 22, 2024
Note that this would need to be limited to background images which are defined inline via
styleattributes, at least to start.Background images which are defined in external CSS files are more difficult to handle. I'm working on prioritizing the loading of such externally-defined background images in #1584, but it may not be feasible to lazy-load them. This is because the detection logic doesn't know up-front which elements have background images, so it doesn't know which to attach
data-od-xpathattributes for. For the LCP element with a background image at least, we might be able to figure out which element detected client-side corresponds with a tag when iterating over the document during optimization through some heuristics, especially if the element has an ID.In any case, I expect that most non-inline background images are going to be used in the page header and so won't need to be lazy-loaded anyway.