Would replacing/removing old pages help improve performance?

[ghost]

After loading many pages, especially ones with images, it seems one common issue with infinite scroll is that increasing memory usage begins to negatively affect the browsing experience, as the scrolling becomes much jerkier and there's a higher chance for the browser to crash. I was wondering if adding an option to limit the number of "present" pages and discard everything else that goes beyond that number limit would help mitigate this in any way. I saw this option in another endless scroll plugin but didn't get a chance to test it.

https://github.com/fredwu/jquery-endless-scroll/blob/master/README.md
(parameter 'pagesToKeep' : The number of 'pages' to keep before either end of the scrolling content are discarded, by default (value set to null) no content will be discarded.)

Would be interested to hear what others think.

[67726e]

@mfoda There is a Pull Request in the works for a maxPages option. This could provide an one route to take. Another is to write this functionality as a behavior, or just as your callback. After you get through so many requests, start taking content out.

[ghost]

Thanks, I didn't see that. Would it be possible to provide some sample code on how to do that through the callback method? I really don't know a lick of Javascript to know where to start. Just a simple "after having loaded X number of pages, start taking out content," as you described.

Cheers

[ghost]

Also I'm looking at the maxPage option and I'm not sure how I can adapt it for that specific issue. As I understood the maxPage option gives the ability to determine how deep you can scroll, i.e. the maximum number of total pages you can load, but there's no removal of old content to improve performance. In my use case I want the user to be able to browse as far into the page as they would like without a limitation on the maximum number of pages they can view, while at the same time making the experience as smooth as possible and minimizing the possibility of browser crash, since as far as I know there is no way to remember which page the user was on and they would have to start all over.

[67726e]

Well if you don't know JS, an example probably isn't going to help... but anyway:

var counter = 1;

$("#infinite-scroll").find(".elements").addClass("loaded-at-" + counter);

$("#infinitescroll").infinitescroll({
  // Skipping options
function(newElements, data, url) {
  counter++;

  // Give our loaded elements a class so we know where to start taking off elements
  $(newElements).addClass("loaded-at-" + counter);

  // Remove any elements from beyond our expiration point
  if (counter > 5) {
    $("#infinitescroll").find(".loaded-at-" + (counter - 5)).remove();
  }
});

This is pretty basic and will take out any elements loaded 5 AJAX calls ago. Off-hand I don't know what implications you may get into involving the position of the scroll bar when the call to remove happens. I would not recommend using this simply for the fact that it gives a very strange experience when the user scrolls back to the top.

I would probably recommend something where you take detach of the top of the page as you scroll down and reattach as you scroll up and vice versa. That would be an ideal solution, but it would be a bit of a pain to implement in a nice manner.

A nicer, and simpler option would be to use the maxPage option (which I haven't gotten around to integrating at the time of writing) and have the user manually change pages after a while to prevent the crash and continue the infinite scroll on the next page.

[ghost]

Thanks for the code snippet. That makes perfect sense the way you implemented it, although I don't think I would have been able to write that on my own. I'm still in that limbo stage with Javascript :-) I'll give it a try and let you know how it goes.

The maxPage option does sound like a more robust solution to look forward to. Kind of unrelated but have there been any fixes for the Back button issue? That and the browser crash are the most common user experience complaints that I've been hearing and it sounds like one of them is on the way to getting addressed.

[67726e]

@mfoda I'm sorry, but I am unaware of any back button issues. Care to elaborate?

[ghost]

I was referring to #230. Basically when I navigate away from an infinite scroll page and hit the Back button I'm taken all the way back to the top of the page and have to scroll down again to where I left off. I've added the line you put to illustrate passing the url to the callback function:

history.replaceState({infiniteScroll:true}, null, url);

But that is simply taking me to the last browsed page, where the infinite scroll functionality is disabled and pagination is in place. So previous content can't be scrolled up to, and subsequent content isn't loaded with infinite scroll and what is displayed is only elements on that one page. Reading the comments I thought this was a temporary solution and a full-fledged Back button functionality is in the planning. Maybe I misunderstood this?

[67726e]

@mfoda That isn't so much of a problem as it is just how browsers work. I cannot override the way browsers handle the buck button, so there is nothing to be done here.

[ghost]

That's good to know. I definitely need to be reading up on all of this. The reason why I thought it would be possible is I stumbled across this plugin while looking for infinite scroll plugins:

https://github.com/Hawkers/scrollAppend

which mentions that it "Uses localStorage so the user won't lose their place when clicking away and returning," and gives you the ability to specify how long to store that cache before expiring. I haven't tested it out myself though so I don't know if it does what I imagine it does.

[67726e]

@mfoda Infinite-Scroll is really more meant as a drop in to add features to a page, but not be the center of attention, which I think you get with something like scrollAppend.

[ghost]

I'm not sure what you mean by that. Do they have different use cases?

[67726e]

I'm just saying, there are different ideas of how things should work on a website. The developer of that plugin thinks that data should be cached and loaded again with an infinite-scroll type plugin. I don't particularly think that is the right answer.

[ghost]

That makes sense. I thought you meant they should be used for different purposes. I think I'll be sticking with Infinite Scroll and hoping for the maxPage option to come soon :-)
Thanks for the quick responses.

[ghost]

Actually I am a bit curious as to why you don't agree with the localStorage approach used in that plugin. Could you please elaborate?

[67726e]

It disregards the true functionality of the browser.

[ghost]

Meaning there are no usability issues, it's just not what localStorage should be used for? Sorry for the barrage of questions, I'd just like to be clear what the pros and cons of each approach is.

[67726e]

Well, I'm not saying that the implementation is a problem, although I could question how performant the storage of large strings of HTML that are then turned into DOM elements is, but rather that you are going against how the browser operates.

When you press the back button, you are going to the page from whence you came. When you then press the forward button you should are getting the page again. The thing is, a GET request should be idempotent, and it is on the server side, but in this case the outcome on the client side would be entirely dependent on what happened at a given state in time. Then, your actions from then on have the potential to change the outcome of later visits to the page.

[ghost]

While my background on this topic isn't extensive enough for me to be comfortable with going into the technical aspect, I understand what you're saying about this being a violation of the way browsers are supposed to work and why you wouldn't condone it as good programming practice. At the same time though I think it's worth considering whether or not this is worth the sacrifice that's made in terms of the user experience. When you use infinite scroll you're typically putting a large amount (if not all) of your content on one page, be it blog posts, pictures, products, comments..etc, with pagination taken away. So when a user navigates away from this page not only are they expecting to be brought back to the exact place where they left off, since this is standard Back button behavior, but they're also going to be irritated by the fact that they've been brought back to the very first page with all previous pages gone (and inaccessible through any on-page search functionality), and that they have to manually scroll down to where they last got to, assuming they still remember that. This is troubling when you have equally good content on a page but the amount of attention each piece is receiving is being determined by the number of scrolls the user has to make before it can be viewed.

Again, I'm not sure how this should be approached but it seems like an important aspect to consider since the whole idea behind infinite scroll is improving user experience.

[67726e]

you wouldn't condone it as good programming practice

Moreso that it violates the functionality, at least semantically.

It really boils down to how rich you want the plugin to be, and your philosophy behind how things should function. Neither my coworkers, superiors, nor myself believe that the proper approach is to do the cache/pre-load is the correct approach.

Of course this again will lead back to the origin of this ticket, being performance. By taking the cache/pre-load route you will wind up with extremely large pages and excessive memory consumption. I think if you start to run into these issues, you may need to reconsider how the site is designed as Infinite Scroll may not be an entirely appropriate fit.

[ghost]

It has gotten me thinking about that. So is the cache/pre-load method the only possible solution for that issue?

[67726e]

In terms of what the user sees when the back button is pressed? No, you could set some form of system up using hashbangs on your URLs to indicate page statue, e.g. /path/to/resource#page55 and utilize a plugin like jQuery BBQ or you could use the history.replaceState as is used in #230

[ghost]

Awesome. I'll check that out. Thanks for everything.

[charanjit-singh]

Thanks