Implemented Implement Lazy Loading...


Well-known member
Actually there is this addon available on the Resource Manager. Thanks @Xon. However, it doesn't work with important addons like Media Gallery.
it would be great have this feature in the core.
Lazy Loading
Lazy loading is a technique for loading web content when it’s needed rather than all at once. Content that is usually downloaded when the web page first loads is instead downloaded as the user requests it, typically from scrolling through the page.

More info:
Normally when a user opens a webpage, the entire page’s contents are downloaded and rendered in a single go. While this allows the browser to cache the web page, there’s no guarantee that the user will actually view all of the downloaded content.

For example, If an entire photo gallery is downloaded but the user leaves after only viewing the first image, then the result is wasted memory and bandwidth.

Instead of bulk loading all of the content when the page is accessed, content can be loaded when the user accesses a part of the page that requires it. With lazy loading, pages are created with placeholder content which is only replaced with actual content when the user needs it.
When someone adds a resource to a web page (image, video, etc.), the resource references a small placeholder. As a user browses the web page, the actual resource is cached by the browser and replaces the placeholder when the resource becomes visible on the user’s screen. For instance, if the user loads a webpage and immediately leaves it, then nothing beyond the top portion of the webpage is loaded.

Lazy Loading’s Impact on Search Engine Optimization

A common pitfall of lazy loading is its impact on a website’s ranking in search engines.

Because resources default to placeholder content, a search engine crawling through the website is likely to misinterpret or ignore the contents of the resource. Lazy loading an entire component of a webpage such as a blog post could result in a search engine bypassing that component, resulting in fewer search engine results due to the content not being indexed.

One trick to overcoming these pitfalls is to provide links to lazy loaded content. This essentially creates a webpage out of the content accessible to search engine crawlers. When a search engine indexes the website, it follows these links and indexes the content it finds. This method essentially structures a lazy loaded website as a traditional website, while still allowing users to load content dynamically.
WordPress, one of the top blogging platforms on the web, provides a lazy loading solution called Infinite Scroll.

As the name suggests, Infinite Scroll continuously loads content as the user scrolls down the page. The page’s footer – normally inaccessible in an infinitely loading web page – is displayed as an overlay beneath the scrolling content. WordPress claims that users read more posts when Infinite Scroll is enabled, as opposed to the traditional page-based approach.

Google takes a different approach for its image search results. As the user scrolls down the page, placeholder images are replaced with thumbnails. After a certain number of images are displayed, a button allows the user to load additional images. By providing this button, Google combines infinite scrolling and lazy loading to create a dynamic hybrid approach.
Lazy loading strikes a balance between optimizing content delivery and streamlining the end user’s experience.

Users connect to content faster, since only a portion of the website needs to be downloaded when a user first opens it.
Enterprises see higher customer retention as content is continuously fed to the user, reducing the chances the user will leave the website.
Enterprises see lower resource costs since content is only delivered when the user needs it, rather than all at once.
Streamlining web content is a vital part of shaping a user’s browsing experience. Dynamically loading resources allows the user to explore more content without having to jump across multiple pages or wait for their browser to refresh. When implemented well, lazy loading can provide additional content to a user without the user even realizing it.

Adding lazy loading can make a website load faster, save bandwidth, and provide a truly uninterrupted browsing session. Almost half of all users who visit a website view only a single page. By continuously adding new content as the user scrolls, lazy loading can make that single view really count.
Source: MaxCDN
Demo: - Lazysizes on Github

Suggestion awaiting your like, Thank you. ajax.gif ➘​
Last edited:
Upvote 77
This suggestion has been implemented. Votes are no longer accepted.
Lazy loading was actually designed because the limitations of http/1.1
With http/2 it's not really necessary anymore because the limitations are gone.

Or that's what I understand. Let me know if you think something different. ;)
Last edited:
I can't find the right article anymore but it's about the multiplexing in http/2 that solves the head-of-line blocking in http 1.1
I post it here when I can find it.
This is a quote from the http/2 github FAQ

Why is HTTP/2 multiplexed?
HTTP/1.x has a problem called “head-of-line blocking,” where effectively only one request can be outstanding on a connection at a time.

HTTP/1.1 tried to fix this with pipelining, but it didn’t completely address the problem (a large or slow response can still block others behind it). Additionally, pipelining has been found very difficult to deploy, because many intermediaries and servers don’t process it correctly.

This forces clients to use a number of heuristics (often guessing) to determine what requests to put on which connection to the origin when; since it’s common for a page to load 10 times (or more) the number of available connections, this can severely impact performance, often resulting in a “waterfall” of blocked requests.

Multiplexing addresses these problems by allowing multiple request and response messages to be in flight at the same time; it’s even possible to intermingle parts of one message with another on the wire.

This, in turn, allows a client to use just one connection per origin to load a page.

Why just one TCP connection?
With HTTP/1, browsers open between four and eight connections per origin. Since many sites use multiple origins, this could mean that a single page load opens more than thirty connections.

One application opening so many connections simultaneously breaks a lot of the assumptions that TCP was built upon; since each connection will start a flood of data in the response, there’s a real risk that buffers in the intervening network will overflow, causing a congestion event and retransmits.

Additionally, using so many connections unfairly monopolizes network resources, “stealing” them from other, better-behaved applications (e.g., VoIP).

Just not sure if you are going to improve things with lazy load if you have http/2, you might actually slow everything down.
I hope that this is being considered for XenForo 2. It would save us a lot of performance and bandwidth.
Implementation in the core would not only be a big win for core functionality, but it would also allow addon developers to apply it to their addons.
Please consider this mainly for mobile users that represents tho majority of today websites visitors.
It should be applied to posts image attachments, BB code media sites and official XF addons like XFMG.
Lazy loading should be discussed separately from infinite scrolling. Lazy loading aims to improve the performance without any visible side effects, whereas infinite scrolling profoundly changes the way a user interacts with the page.

For context, I have published an add-on that uses lazy-loading for the media sites it supports. I'm happy with the results, so I looked into expanding this functionality to images. I found that in most cases, it didn't make a measurable difference in terms of performance. Unless the page contains a particularly big GIF image, it doesn't seem worth it. One big issue with lazy-loading images is that while the dimensions of media embeds are usually set/known in advance, the dimensions of user-submitted images are not. As new images are loaded (e.g. during scrolling) the layout needs to be recalculated and some elements will jump around. In short, lazy-loading images is difficult to implement properly (in a non-disruptive way) and it doesn't really improve an average page.
To be honest i think it depends on each admin.
Some may need it.
Some may not. :)

If it will be in core, then that would be great. As long as there is an option to turn it off. :)
With native lazy loading support for images and iframes being turned on by default in Chrome 75, it would be nice if XF could add support for the new loading attribute as this could significantly speed up loading of up threads with a lot of images.

Lazy loading was actually designed because the limitations of http/1.1
With http/2 it's not really necessary anymore because the limitations are gone.
That's just plain wrong :)
HTTP/2 optimizes/fixes TCP head of line blocking by multiplexing several requests/responses into a single stream, it does not automagically increase bandwidth of clients.

If you have a lot of big images on a single page you will for sure notice a significant speedup especiallally on bandwidth-restricted mobile devices, even if the site is using HTTP/2 with 0-RTT TLS 1.3 or even QUIC (aka upcoming HTTP/3).

That's pure math:
If the page contains 100 images x 100 KB, that's ~ 10 MB and will take at least ~ 60 seconds (more likely 100+ seconds) on a 3G connection before the document onload fires.
With lazy loading, it might only need to load the first few images (those that are immediately in viewport + some expand) instead of all to fire the onload event.
Last edited:
Personally I think if a page has 100 images that aren't thumbnailed there's a bigger issue. I do like the concept of lazy loading, as long as it doesn't incentivize bad practices.
You can easily reach 100 images on one page if your users like to put full sizes images into their posts.

If you have 20 posts per page (which is a quite reasonable number) that's just 5 images/post on average - sometimes we have posts with 10-20 images.

Of yourse you could try to force user to post less images/post, to only post thumbnails or lower the amount of posts per page, but generally users do not like to be limited this way.
Top Bottom