Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Performance with infinite scroll or a lot of dom elements?

I have a question on a big # of dom elmenets and performance.

Let's say I have 6000 dom elements on a page and the number of the elements can be increased as a user interact with the page (user scrolls to create a new dom element) like twitter.

To improve the performance of the page, I can think of only two things.

  1. set display to none to invisible items to avoid reflow
  2. remove invisible items from the dom then re-add them as needed.

Are they any other ways of improving a page with a lot of dom elements?

like image 786
Moon Avatar asked Sep 27 '12 02:09

Moon


People also ask

Does infinite scroll improve performance?

Performance degrades If you're using infinite scrolling on a long page, you're constantly loading more and more content into memory. This will have a negative impact on page performance, since the browser has much more work to do in order to render the page.

What is the point of infinite scroll?

What Is Infinite Scroll? A web design technique where, as the user scrolls down a page, more content automatically and continuously loads at the bottom, eliminating the user's need to click to the next page. The idea behind infinite scroll is that it allows people to enjoy a frictionless browsing experience.

What is endless scrolling called?

Infinite scroll is a user experience (UX) practice in which content continually loads when a user reaches the bottom of the page. This creates the experience of an endless flow of information on a single, seemingly never-ending page.

How is infinite scroll implemented?

Infinite scrolling is when a user reaches the bottom of a page and new content is fetched and loaded so the user can continue to scroll in a relatively seamless experience. This is an alternative to other pagination solutions which use numbered pages or buttons that load more content.


1 Answers

We had to deal with a similar problem on FoldingText. As the document grew larger, more line elements and associated span elements were created. The browser engine just seemed to choke, and so a better solution needed to be found.

Here's what we did, may or may not be useful for your purposes:

Visualize the entire page as a long document, and the browser viewport as the lens for a specific part of the long document. You really only have to show the part within the lens.

So the first part is to calculate the visible view port. (This depends on how your elements are placed, absolute / fixed / default)

var top = document.scrollTop; var width = window.innerWidth; var height = window.innerHeight; 

Some more resources to find a more cross-browser based viewport:

Get the browser viewport dimensions with JavaScript

Cross-browser method for detecting the scrollTop of the browser window

Second, you need a data structure to know which elements are visible in that area

We already had a balanced binary search tree in place for text editing, so we extended it to manage line heights too, so this part for us was relatively easy. I don't think you'll need a complex data structure for managing your element heights; a simple array or object might do fine. Just make sure you can query heights and dimensions easily on it. Now, how would you get the height data for all your elements. A very simple (but computationally expensive for large amounts of elements!)

var boundingRect = element.getBoundingClientRect() 

I'm talking in terms of pure javascript, but if you're using jQuery $.offset, $.position, and methods listed here would be quite helpful.

Again, using a data structure is important only as a cache, but if you want, you could do it on the fly (though as I've stated these operations are expensive). Also, beware of changing css styles and calling these methods. These functions force redraw, so you'll see a performance issue.

Lastly, just replace the elements offscreen with a single, say <div> element with calculated height

  • Now, you have heights for all the elements stored in your Data structure, query all the elements that lie before the visible viewport.

  • Create a <div> with css height set (in pixels) to the sum of the element heights

  • Mark it with a class name so that you know its a filler div
  • Remove all the elements from the dom that this div covers
  • insert this newly created div instead

Repeat for elements that lie after the visible viewport.

Look for scroll and resize events. On each scroll, you will need to go back to your data structure, remove the filler divs, create elements that were previously removed from screen, and accordingly add new filler divs.

:) It's a long, complex method, but for large documents it increased our performance by a large margin.

tl;dr

I'm not sure I explained it properly, but the gist of this method is:

  • Know the vertical dimensions of your elements
  • Know the scrolled view port
  • Represent all off-screen elements with a single div (height equal to the sum of all element heights it covers for)
  • You will need two divs in total at any given time, one for elements above the visible viewport, one for elements below.
  • Keep track of the view port by listening for scroll and resize events. Recreate the divs and visible elements accordingly

Hope this helps.

like image 151
Mutahhir Avatar answered Sep 19 '22 21:09

Mutahhir