2 ms·
Infinite scroll can be a terrible anti-pattern when implemented poorly, and it's terribly difficult to pull off correctly. I dealt with this issue at the last
by bzalasky 12y ago
Infinite scroll can be a terrible anti-pattern when implemented poorly, and it's terribly difficult to pull off correctly.
I dealt with this issue at the last startup I worked at (Stipple, now defunct :(). We had a masonry feed of annotated images with associated media like videos, audio and product links that was infinitely scrolling. What this meant in practice is that you could paginate about 20 times before the fan on your macbook would start roaring.
LinkedIn had a great article about year or two ago about optimizing infinitely scrolling feeds, however, it only applies to single column feeds. Masonry layouts make things much more difficult. That being said, one of the benchmarks in that article mentioned toggling visibility improving performance (not what they settled on, but still a significant gain). This is what I was able to implement. We had to query the DOM to detect when an image in the feed was moving in and out of the screen with a buffer equal to screen height. With this in place, users could paginate 50+ times without trouble (at a solid framerate), though they would've eventually hit problems if they kept scrolling too long.
TLDR; I hate masonry layouts for performance reasons.