Performance while scrolling

[Tushar Mathur]

I observed that the images are resized on the client size. It seems like its not the best for when you have a list of retina images that you want to scroll thru —
http://www.html5rocks.com/en/tutorials/speed/scrolling/#toc-resizing

Which states —

If you're sending large images to a device and then scaling them down using CSS or image dimension attributes, you're more likely to see this happen. Of course the amount by which the browser has to rescale images, and the frequency with which it has to do this, is going to affect your page's performance as they happen on the main browser thread, and therefore block other work from taking place.
One solution that I think might work is to simply hide the images at the time of scrolling and show the scrolling stops. This would definitely effect the user's experience I think.

I would really like to know your thoughts on how we can improve scroll perfs here?

[John Newman]

That's a great thought and I'd love to start brainstorming about it. Have you actually noticed performance problems? Right now retina.js will always load the page using small, 1x images. It will then make subsequent requests to the server to see if high-res variants exist and swap them out if they do. Because each request happens subsequent to finishing the page load, images are actually swapped out asynchronously. It's true that the work takes place on the main browser thread, but each swap out is actually non-blocking and it only happens once.

The html5rocks tutorial mentions that when the browser needs to resize a lot of large images as part of it's paint procedure, that you can sometimes notice some less than ideal scrolling effects. The problem is, that's the nature of retina images. They have to be 2 or 3 times larger than the area they're designed to fit in and then smashed in there in order to get the resolution benefits. So there's really no way to resize them somewhere other than the client side. In effect, that would be the same as serving up a 1x image.

As for your idea for a solution, I think it's interesting. I'm not sure if it's something we'd want to build directly into the script because I can see a lot of users freaking out about why all of their images are disappearing on scroll. And if hiding them is the right option, I can imagine a lot of different users wanting to hide images in a lot of different ways that work best for their needs. One fun thought I'm having as I write this is that, since the browser caches all the loaded images by default, you might theoretically be able to cache all the 1x URLs and swap them back in when a scroll begins, then swap them back out for 2x images when the scrolling stops. Since all of those images are cached, the browser shouldn't need to make any requests. You wouldn't have to hide your images, and you might get some performance benefits. But it's something I'd want to play with and test out.