Different Infinite Scroll

[linkchilla]

I like to request a different/better Infinite Scroll. Infinite Scroll is great and the current one works ok, but is also kind of a CPU/GPU Hog. Together with the many CSS Transitions it all feels kind of slow and stops at the page end, even when the images are already coming from the cache. So it kind of interrupts the experience, at least on weaker client machines like my trusted Thinkpad Laptop. It has somewhat weaker intel graphics, but for instance the current scroller on unspash works absolutely great. Also, less CPU/GPU use means longer battery life for mobile users.

Thoughts?

 

[Rodolfo]

Is quite a challenge to achieve that in HTML, I believe that unless browsers get better capabilities, it can't be achieved in the same way we experience a dedicated app.

The problem is that for each image, you must add a DOM node thus increasing the memory required by the browser. You can suppress those nodes based on the viewport, quite similar to how games only work on the content that you see at a given time, but the problem is that when you store those nodes (let's say list objects) you also do it on memory. A better approach will be to keep these as local storage (objects and compiled templates) which grants 5-10MB depending on the browser and on the fly re-populate those elements that are too far away in the viewport. Unfortunately, such experience won't be fluid because at web we have limited access to the machine resources, so it will do the job but it won't feel fluid enough.

You have to remember that the listing system was built in 2012 so is quite old right now. I have made several improvements there but the bottom line is that for huge listings we need a new tech here. What I'm seeing a lot are hybrid listing systems where you infinite scroll like 3 pages and then you do conventional navigation. That works awesome, gets the best from both techniques, you get more pageviews, you engage the user, etc.

In any case, I agree on that endless listings should get improved but I think that it won't happen in 3.X.

 

[linkchilla]

Is quite a challenge to achieve that in HTML, I believe that unless browsers get better capabilities, it can't be achieved in the same way we experience a dedicated app.

That's obvious true, but it seems unsplash has found a way very close to it. That scroller on their website really rocks. I've no idea how they do it, but it is damn good. Maybe go take a peek? 🙂

In any case, I agree on that endless listings should get improved but I think that it won't happen in 3.X.

How about then, if it is possible, that the current scroller is triggered earlier? As soon as the user begins to scroll maybe?

 

[Rodolfo]

You can compare unsplash with this. They list few nodes with little sub-nodes while Chevereto adds several nodes with several sub-levels, is like comparing a bus vs car, being Chevereto like a bus for 200 people.

What I do in Chevereto, is that I allow you to customize how many images you want to list per load, so it detects when you list too many stuff and it revers to classic pagination. It does all auto, you won't even notice it. Here, check that page 5 loads all the 5 pages and works as endless, but from page 6 it will revert to classic pagination. This is designed in the way that when the user jumps to an image and then returning to the listing it will work as classic pagination, leveraging the load.

So, what I just told you before is that the system should do a hybrid pagination. You load 1 page and it sub-load 2 extra pages and then it requires to jump to the next page. Is like what it does right now but at this time the system won't stop listing until you jump to an image when page > 6.

 

[linkchilla]

[...] too many stuff and it revers to classic pagination. It does all auto, you won't even notice it. Here, check that page 5 loads all the 5 pages and works as endless, but from page 6 it will revert to classic pagination. This is designed in the way that when the user jumps to an image and then returning to the listing it will work as classic pagination, leveraging the load.

Aah, now I get it. I must admit, that I noticed that behavior on my own installation before and thought it was an error. 🙄 Thanks for the explanation.

However, the CSS transitions seems heavy on the GPU/CPU,too. Would disabling all of these give a better experience? I tried, lowering the number of rows and a custom style:

* {
 -o-transition-property: none !important;
 -moz-transition-property: none !important;
 -ms-transition-property: none !important;
 -webkit-transition-property: none !important;
 transition-property: none !important;
}

That helped and disabled all transitions on the pages, but not in the scroller. Do you have maybe a tip for me? If it is too much of a hassle, I rather drop it, because it works and can be tweaked later. I have other problems, like putting content and users on the server... 🙂

Thanks again.

 

[Rodolfo]

Is not about CSS, is just too many nodes + JS. The thing is already optimized, most likely you list too much stuff?

 

[linkchilla]

I was playing around with lowering the number of rows and number of items/page, but the effect is almost irrelevant. It makes barely a difference if I have 7 or 4 Rows and/or 24 or even only 12 items/page. Which is a good thing, I guess. The final rendering of the page still is a CPU/GPU Hog and takes way to long for smooth scrolling. I can see on my terminal log, that the server is long ready with delivering all the images and the client takes still a few seconds to render the page after that. I know my client system is on the low end, gfx performance wise. But usually I don't have much such problems, except perhaps a few sites, that have a very high amount animated advertising or use full-screen transitions. But these sites usually tend to have less to nothing in the content, so I stay away from those sites. 🙂 But anyway, its fine. I let it be for now and hope that the scroller someday gets a nice rework. Thank you for support.