Late loading of images on scroll

[obulat]

Description

The search grid uses the native loading: lazy attribute for images to improve performance by not loading the images below the viewport.

This is harming user experience, especially on mobile, because the user sees flickering of images that are being loaded and replace the gray squares on the screen when they scroll, instead of a grid of loaded images.

Screen_Recording_20220319-135722_Chrome.mp4

It is impossible to change the threshold of visibility for native lazy loading. In addition, it differs between different browsers.

It is better to implement custom lazy-loading based on an Intersection Observer, and load the images for one screen below the viewport to ensure that the user always sees loaded images.

Reproduction

1. Open the site on a mobile.
2. Search for something and scroll thought the results.
3. See error: gray squares that are being replaced with images at the bottom of the screen, and create unpleasant flickering experience.

Environment

This happens both on the desktop and the mobile, but it is worse on a mobile device with a slow network connection.

Resolution

• 🙋 I would be interested in resolving this bug.

[zackkrida]

I disagree that this is a problem or that a custom js lazy loading solution would be preferable, but I'm curious what others think and open to considering it.

Edit: I'll elaborate more today, wrote this on my phone

[zackkrida]

To elaborate, browsers typically have more heuristics with which to determine when to load an image than our own code ever could. Additionally:

Browser-level lazy loading also ensures that deferred loading of images still works even if JavaScript is disabled on the client.

Also, I think this is an interesting consideration. I don't think the problem in your screenshot is that the browser is firing off the 'load this image, now!' command at the wrong time, but that the network request to fetch the image takes too long. Even with a custom JS solution, if we set the image downloads to fire off when the image is "one screen below the viewport", if the user scrolls the length of one screen in one second and the image takes three seconds to load, they'll still experience the same problem you've described in the issue. You can observe that the problem is non-existient on my super fast desktop connection, for example:

CleanShot.2022-03-21.at.20.31.25.mp4

Perhaps the best thing we could do here is look into adding support for different sizes, minification, and webp support to our thumbnail cache, so that send the user the smallest possible images and improve network speeds. Currently the thumbnails are 600px wide on their largest axis, but they never display nearly this large in the UI.