Hi @florianbrinkmann
Thank you for replying.
I hear you re: loading more data for each image. Considering that we are trying to improve page loading speed with lazy loading that does seem counter-intuitive.
But I think there are also other considerations to take into account. One being the user experience. I do think that for users who scroll rapidly enough on slow enough connections to come across blank spaces in a layout and for those to be populated with lazy loaded images while they wait and wonder about what’s going on there is a disruptive and potentially frustrating experience.
Now I know that we can change the threshold to try and prevent that from happening, but that can also quickly become counterproductive and just lead to less lazy loading across the board.
And I know you also have available the spinner which can show that at least something is being loaded. But I quote from smashingmagazine:
Looped Animation
Since the majority of looped animation is indeterminate and serve a variety of types of delays, including long ones, this type of progress indicator tends to have negative connotations. For example, a default loading icon in Apple iOS (spinner of gray lines radiating from a central point area) serves a variety of operating system functions, indicating the status of everything from device boot to problems connecting to network or loading data. Because of that, users don’t like to see only a loading spinner with no indication of progress or time.
And I personally would agree that users often have negative associations with loading spinners, I certainly do.
I would also think that another benefit of automatically generating placeholders that match the size or aspect ratio of the image would eliminate any chance of layout shifts happening. And with Google’s new focus on “page experience” over just “page speed” and cumulative layout shift being a core factor measured in that, there is a significant benefit to this because Google will be making that a search ranking factor in 2021.
Again I know image width and height can be specified in themes and thereby prevent layout shifts in masonry grids and such, but not all themes/editors/page builders consistently do this and not all users have the ability to correct for that themselves.
So it is to that end that I find LQIP interesting in lazy loading. BUT…I completely agree, loading of any additional data needs to be very carefully considered and also always be optional.
Perhaps something like SQIP is interesting – see partway into this article – because it seems to lead to placeholders that are generally bytes in size rather than KB’s. Although offhand I’m not sure whether regular LQIP can’t also achieve the same sort of sizes.
Either which way, thank you for considering the feature request, even if you don’t decide to go with it.
Kind regards,
Jonas
