Hacker News Reader

Comment by chrismorgan | Hacker News Reader

You know what’s an almost ideal image component? <img>. Sure, browsers could be a little cleverer about prioritising image loading, and I wish everyone would prefer to slim their images down somewhat, but compared with all other attempts I have encountered (with no exceptions), <img> is almost ideal.

I unconditionally hate all scroll-based lazy loading of images. Any other forms of lazy loading of images such as you outline in this post I will also hate, p≥0.96. And attempts to be clever like detecting high latency and working otherwise in such situations normally mess up what I want to happen.

I’ve written about these things before and I’ll doubtless write about it again; https://news.ycombinator.com/item?id=16518010 is the last time I wrote about it on HN and some discussion arose. (The previous time was on the SVG image placeholders article linked elsewhere in these comments.)

View on HN

Most of this comment is just you being dismissive about an idea without any real reason presented for being dismissive. The only useful bit here is actually in your linked comment which most people will probably not see and that is that lazy loaded images tend to fail a lot on poor internet connections. I would argue that even in that case, lazy loading images arent necessarily bad depending on the situation: imagine a site like imgur, where you will likely browse to another page without ever loading all of the images. In that case, the browser would still have loaded the image if it were an img tag and this way you get to the next page faster. Sometimes the browser will cancel the img download, but its not reliable. If the js were coded to handle errors on loading the image, that would probably be a better situation overall.

It’s much worse than just the potential for failure, as I indicate in other places I’ve written about it. If I ever see evidence that scroll-based lazy loading has occurred, it has failed in its mission: it didn’t load the image in time. And in practice, this happens a lot of the time, especially in higher latency situations. You can’t sufficiently-well predict what the user is going to do and so only load it just in time. It doesn’t work.

I am inspired by your grumbling to write a blog post entitled “Scroll-based lazy loading of images is always bad”. I won’t publish it for a while so I can treat the subject methodically (and I’m busy for the rest of today), but it will come.

Thanks for the imgur comparison; the wording I’ve used does fall down there; in my mind I had distinguished scroll-based lazy loading and scroll-based lazy loading of images. When talking about scroll-based lazy loading of images, I meant where you have content that contains images, rather than situations where the images are the content. (That is, I’m talking about lazy loading just the <img>, not lazy loading content in general.) There are definitely applications for which loading everything up-front is impossible (e.g. imgur infinite scrolling on mobile) or impractical (e.g. showing all the 10,000 messages in a mailbox in an email client that deliberately eschews pagination, like FastMail); in such situations, lazy loading is necessary and while it will often be annoying and imperfect there is and can be no better solution.

Where images are embedded in the content, however, I think that my position is still reasonable; there is an alternative: just load eagerly rather than lazily. Now articles and blog posts are the primary application I have in mind, and I can’t think of any other applications where my position would not hold—given the caveats of interpretation specified in the previous paragraph—but I’m willing to hear other suggestions.

I much prefer a pixelated or blurry preview image first and then the real image instead of waiting 20 years for images to load staring at a blank page. i notice the perceived speed difference on websites that do this and those that don't. Medium does it well and this react component image approach is similar. And once it is loaded, it is an <img />

Images load in the background, so the other content will be available before the images are all finished loading.

As a rule, I’d much rather see nothing or a solid colour than a pixelated or blurred preview of the image; I find it and the transition surprisingly disconcerting. I mentioned this at https://news.ycombinator.com/item?id=16516126#16558042 and have heard others agree with me.

This component supports solid color as placeholder. The same way as Google Images or Pinterest do

Ok I see your use case: you load page on good connection, then connection get worse and images are not loaded when you scroll to it.

This component allows to retry image load (click on it).

It can be even more smart, like if network is good go ahead and download everything. Need to think about it

The failure case is worse than that: I may not have a connection by that time.

Even if I do have a connection and it all succeeds, if the image is not there when I scroll to it, the lazy loader has failed in its job. And that’s pretty much unavoidable in general content—people don’t always scroll smoothly through a page; I may jump down a page at a time, or skim through some headings looking at illustrations that haven’t loaded yet because they only figured I might be interested in them a bit under half a second ago, and latency is half a second plus probably another couple of tenths of a second of annoying fade-in transition. The possibilities are endless.

Come live in Australia for a bit and deliberately use sites from the US with scroll-based lazy-loading: I predict you will rapidly acquire a healthy dislike for the technique! :-)

I'll definitely take your use case into the consideration in the future

By handling failure nicely, your component seems to be better than any others I’ve heard of. (Thanks for doing that.) It’s even improving over browsers’ handling of it (right click, reload image) in situations where the intrinsic width and height of the image are not specified or overridden in CSS, which causes the <img> to collapse to generally the alt text height. (Responsiveness is often obtained with images via { max-width: 100%; height: auto }, but browsers don’t use the intrinsic width and height of the image to calculate the auto height. Hmm, I think this could be considered a bug; I might try my luck filing it against Gecko.)

But still, as a user I would consistently prefer a plain <img> to any fanciness.

Reply on news.ycombinator.com