Why does HTML’s Lazy Load differ so much across browsers?
The ‘LazyLoad’ feature in HTML delays the loading of data for elements such as images and iframes until they are needed.
However, the actual behavior significantly differs from the commonly perceived notion of ‘when they come into the user’s view’.
<img loading="lazy" width="800" height="461" src="/images/mamorioTag.webp">This is because the interpretation of ‘when needed’ varies greatly among browsers, which is reflective of the different philosophies each company has towards user experience.
I have created a page for measurement purposes to empirically test the differences across various browsers.
Measurement Method and Results
I created a page that measures the distance (in pixels) from the source to the center of the viewport at the moment the lazy load is triggered.
export default function Home() {
const iframeDistance = 4000;
const [showImage, setShowImage] = useState(false);
const imageRef = useRef(null);
const toggleImage = () => {
setShowImage(!showImage);
}; return (
<div>
<div style={{ background: 'gray', height: `${iframeDistance}px` }} >
<button onClick={toggleImage}>putImage</button>
{showImage && <img src="images/testcat.jpg" alt="testcat" />}
</div>
<img
ref={imageRef} // Attach the ref to the image
src="images/testcat2.webp"
alt="Business Image"
loading='lazy'
onLoad={() => {
const distanceToCenter = calculateDistanceToViewportCenter();
alert(`lazyload fired!: Current scroll position: ${window.scrollY}px, distance to viewport center: ${distanceToCenter}px, Browser: ${navigator.appName}, Version: ${navigator.appVersion}`);
}}
/>
</div>
);
}
I targeted two types of sources: iframes and images. Furthermore, I conducted measurements under two different conditions: one where a 4000px div element and a button are the only things loaded, and another where images have already been loaded.
For testing the loading of images, visit the page: https://iototaku.github.io/lazytestimage/
For testing the loading of iframes, visit the page: https://iototaku.github.io/lazytestiframe/
The results were very interesting, as follows.
Safari: delay until just before the user sees it
A unique feature of Safari on both Mac and iOS is that iframes are not loaded until the user scrolls very close to the element.
iFrames can be a troublesome element for web service providers. While they allow for the integration of rich content like YouTube videos into their services, they also pose a risk of degrading the overall site performance and introducing bugs due to the execution of uncontrollable JavaScript.
The extreme delay strategy that Safari employs for iFrames might stem from a design philosophy similar to iOS’s tableView, which delays the loading of elements not currently in view to conserve memory usage.
Chrome and Edge: Preference for anticipation over latency
Chrome’s strategy seems to be to flexibly change the amount of delay based on the connection speed and the amount of data already loaded, but actual measurements show that even areas well below the ViewPort (more than 2000px) are preempted and become the target of loading even if lazy is specified.
I originally started this investigation when I encountered a problem that no matter how much I specified lazy load for the iframe at the bottom of the screen, it would load the moment the page loaded in Chrome on my PC.
If you want to prioritize the display speed of the top page by having Chrome send the loading of the area not seen by the user, you need to use a different strategy such as using the IntersectionObserver instead of lazy load.
The reason why Chrome on PC prioritizes anticipation over lazy may be due to the experience of successfully improving usability by devouring without hesitation in an environment with ample memory and communication environment such as PC.
Chrome for Android: FCP Supremacy in Mobile
Chrome on Android has a much longer image lazy load setting than Safari on iOS, but once an image is loaded before the element for which Lazy Load is specified, neither the image nor the iframe will apply any lazy load.
While it shares the prioritization of preloading over delays with Chrome on PC, the specification that images should not be placed in the area first visible to the user (FCP) can be considered an extreme adaptation for mobile.
Overall, while Apple emphasizes ‘smoothness’, Google’s design philosophy could be said to supremely value the ‘clarity’ of information contained within the FCP.
It is also important for their search engine crawlers to have a complete representation of what they need to know on the page the moment it opens and finishes loading.
This is also well reflected in Google’s Speed indicator’s emphasis on FCP supremacy.
Firefox: no delay for iframe
Surprisingly, when we performed the measurements in Firefox, the iframe delay loading did not take effect at all. A slightly longer delay (1600px) is applied to the image than in Chrome.
To be honest I do not know for what reason Mozilla formulated such a specification and I have the impression that firefox’s design philosophy is somewhat chaotic.
They have also announced that this problem will be remedied in the next version that I have tested.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/121#html
Conclusion
HTML’s LazyLoad is indeed an effective strategy for enhancing frontend display speed by delaying the loading of large resources like images. However, there is considerable variation in how different browsers interpret when a resource needs to be loaded. Due to these discrepancies, it is essential to verify the actual behavior in the browsers most commonly used by your target audience.
