I think I kind of hate lazy loading
By @edent
· accessibility HTML5 web · 14 comments · 300 words · read ~6,840 times.
Yesterday I was on a train. I clicked on a link and my browser loaded a long article for me to read. Halfway through reading it, the train went into a tunnel and I lost signal.
That meant I couldn't see the images on the other half of the page for the rest of the journey. I had a sea of broken images.
Even though the page had fully loaded, the images were set to "lazy" loading. When my browser sees <img src="example.jpg" loading="lazy" /> it defers downloading the picture until it is about to scroll into view.
There's a few reasons why this is a good thing. If I leave the page before scrolling down, the browser doesn't waste time, energy, or bandwidth downloading images which will never be seen. That's good for my battery life and cheaper for my bill. It also saves the server from flinging bits around the world which are promptly trashed0.
And yet...
It seems that every time I'm on a train - or somewhere else with spotty Internet access - I run in to a situation where I previously had plenty of bandwidth and battery, but my user-agent decided it knew best. So it didn't attempt to load images until after I lost signal.
There's no way to disable Lazy Loading on Android Chrome or Android Firefox.
So, I guess I'm stuck. Lazy loading seems like one of those things which is great in certain circumstances, but has a pretty horrible failure mode1.
Anyone else feel this way?
Ian says:
I have a thought that one day I will fix this on my site -- by loading a low-res holding image and then lazy loading the high-res one when needed.
That way you still get a gist of the image if you lose connection.
+1. And it would be even cooler if the first X bytes of JPEGs could be fetched, to grab the thumbnail to use as the LQIP (Low Quality Image Placeholder).
Hey - TIL lazy loading fetches the first 2048 bytes ... but only when the load is triggered (for image sizing purposes, to reduce content shift).
DinoNerd says:
My experience at Apple was that the developers didn't test situations with variable internet coverage, and didn't respond well to bug reports featuring such events. (At Apple, everyone is expected to use company-supplied devices running pre-release software and report any bugs encountered. This included using them in one's personal life; they actively encouraged installing games and other obviously non-work software.) So I took my company phone on vacation, and filed plenty of bugs, some of them about unwanted effects of driving in and out of cellular coverage areas.
I've never worked for Google, so am unfamiliar with their internal attitudes, but generally it's tweedledum and tweedledee, including hiring from the same pool of developers. At a guess, a bunch of very urban youngsters don't believe in their guts that spotty internet coverage is a thing, except maybe in some third world dystopia. They probably do believe it's possible to have no internet coverage at all, but they simply don't think of intermittent coverage.
JavaScript-based lazy-loading is even worse, as it breaks archival projects like the WayBack Machine.
The other reason to hate lazy-loading is because I open a certain page in background, see it's finished loading, then quickly scroll it to take a quick look and find the exact images I want... Only to have to wait again for them to load... Likewise for those JavaScript-heavy pages that have paragraphs and images fading in as you scroll, making it impossible to quickly find the relevant content. I'm now assuming such pages have no relevant content at all.
Lazy loading sucks. Especially the JS implementations of them -- it's almost as if the
<img>tag is some hyper-advanced new addition to the HTML standards that not everyone uses yet.I also hate low-quality temporary stand-in images. They're all about making a page "look" full without actually providing any function or improvement to the user; ie I think they're vanity. Not once has a blurry image in an article or post ever given me any value. "Page-res" versions that link to high-res versions work, but "thumbnail" res versions only works if your pictures are unlabelled and the user needs to sift through dozens to find one (ie an album rather than a standard webpage). Otherwise they're useless, the user knows the context of your image and wants the actual detail, not a vaseline smeared photograph.
Tim says:
For some reason I suppose I always assumed (I'm not a web developer) that "lazy" on the web worked like low-priority QoS classes: they would simply run only after every high-priority (user-initiated) task was complete.
It does seem bizarre to me that my web browser knows I'm on mains power, I have a high-bandwidth wired network connection, my CPU has many cores which are sitting idle, and it's using a wire protocol with compression and prioritization and multiplexing, and yet it doesn't want to spend a couple milliseconds downloading a small resource in the background before I'll (probably) need it.
mikael says:
about:config dom.image-lazy-loading.enabled
@edent says:
Did you actually try that on the Android version of Firefox?
Because, sadly, that isn't supported. See https://connect.mozilla.org/t5/ideas/firefox-for-android-about-config/idi-p/8071 and https://discourse.mozilla.org/t/about-config-missing/66537/38
mikael says:
Oh sorry, I use the Iceraven fork. Works there. Figured it wasn't fork specific.
raizo says:
IMO the best solution to this would be to load a low resolution version of the image instead of completely ignoring the image until it gets into the view.
ReD says:
I found this for chrom* : https://chrome.google.com/webstore/detail/load-lazyload-images/llenpijlflekljkpjnbnmkfeakfmlcmb
@edent says:
Doesn't work on Android though.
Turn off JS and lazy loading will also be disabled! Okay, there might be side effects ... Seriously: There should be a setting in the browser to change between eager, lazy and deferred loading (the latter loading when CPU + network are idle).
More comments on Mastodon.