So today at Vendasta, we had a meeting to deal with outstanding bugs with our, soon to be released for testing, website: StepRep.
Within this meeting we went through each bug and decided who should deal with what. One of the bug was the fact that the browser began to “bog” down after hundreds of entries were loaded into the page’s dom.
This bug was assigned to me, seeing as I wrote the majority of the javascript for this site, it appeared to be simply overloading the page with too many event handlers, etc.
I figured this was an obvious and unavoidable problem for this sprint.
What happens is, once there are hundreds of entries loaded into the page, it becomes virtually unusable. Scrolling is delayed to the point that if you were to fling the mouse wheel up and down several times or even drag the scrollbar, you would be waiting for the browser to catch up for 5+ seconds. Unacceptable!
I pondered some solutions having to do with hiding unseen elements on the page, (apparently, only the number of elements visible to the user cause performance issues), or pagination, etc.
While searching Google to see if anyone else had found performance degradation upon displaying upwards of a thousand dom elements, I found nothing. Realizing I was scrolling through nearly a hundred Google results, I became curious how many elements were on that page.
In the FireBug console I ran document.getElementsByTagName( ‘*’ ).length, with a little over 2000 dom elements as well, the lag shown in our site couldn’t have anything to do with the number of dom elements.
Was It possible that it had something to do with the number of graphics on the page or the way the YUI Grids / YUI Buttons were built?
I removed CSS until the site remained usable despite the enormous number of entries displayed. Then, I narrowed it down to one stylesheet, then, to one line in one stylesheet.
The culprit: overflow: auto;
This property at first sight appeared to be a life saver! In this context it was used to force parents of floated elements to continue to wrap their children. This meant no more <br class="clearer" />’s!
Just a little note: Unless you plan to have a small number of elements with the overflow property set to auto applied to them, Firefox may cause a very poor end-user experience!