One of our community members suggested using loading="lazy" for all images on DEV. Pros are pretty clear to me. But are there any cons of this? Any kind of gotchas or edge cases we should watch out for?
If not, why isn't that the default for loading images in browser?
I think conceivably if there is an image you know you want showing up ASAP, you'd want to set
loading="eager"on those ones..... But for the most part, the lazy images already above the fold will be loading more or less instantly.All else equal, lazy is the way to go, but if we see that some images are being wrongly deferred, we could instruct the browser otherwise.
Then I kinda wonder why
loading="lazy"isn't the default behavior for browsers (those that support it). It sounds like it's the way to go in 99% of the cases. And for the rest of the cases, you setloading="eager"or whatever is appropriate to overwrite default behavior.it is costly for browsers to calculate the current position of each image and cross-reference the scrollbar data, in addition to doing such a thing they would break various image-based tracker mechanisms
That second part sounds like a net win to me.
you're right @ben , lazy load sucks.
possibly that's the reason that many here have avoided Medium to use the dev.to which appears to be much faster and stable precisely by avoiding lazy load.
intinite load is a valid choice, but lazy load is a lazy dev thing 😆
I don't know how Medium's lazy load is implemented, but I hate it. Most times, the images remain permanently stuck loading. Seen this on a few other sites too. IMO, it's unnecessary.
I'm on a slow-ish connection, but I prefer just having the images load at once, so I know I can use the entire page. Lazy loading to me seems like one of those cool optimisations with debatable impact in the real world.
I thought your question was really interesting. Why not lazy everything?? I thought maybe the browser implementer's might have considered this and here is what I could find.
Blink LazyImages (public) Doc
docs.google.com/document/d/1e8ZbVy...
Blink LazyLoad Design Doc (public) Doc
docs.google.com/document/d/1e8ZbVy...
The most relevant section is the "Compatibility risks" from both documents.
Summarizing here if you dont want to read the source material. The risks all seem marginal. The most likely one to have impact to dev.to is change in load pattern in how images are accessed that MAY have an impact on your servers. If you are loading your images from s3 or a cdn I would not expect any impact.
Also if you are doing any analytics via images, counting image loads, or tracking pixels it can mess with statistics. But shrug emoji
Some websites expect that all images on the page load without delay. If browsers started lazy-loading images by default, those sites could become buggy. If there’s one thing that browsers try to avoid, it’s breaking websites like that.
Can you elaborate which websites you have in mind, which expects all images loaded without delay?
I can only think of artsy / brutalism websites and Websites who are using basic 360° Product Images
I’m just assuming. Generally speaking, for any behavior in a browser, there will be some websites that depend on that behavior. Even bugs. If a browser has a buggy implementation, some websites will start depending on those bugs, and fixing the bugs in the browser will cause bugs on the websites.
Is it possible to default img tags to lazy load via browser extension? It'd be an interesting experiment to see what breaks from the point of view of end users.