4

I have an application that displays a page with 5-10000 rows in a table element and has a drop down menu that switches to other views with a similar structure. Currently I do an async request when switching between views (I also clear/remove the current view from the document) and load the appropriate list each time; however, I was thinking of

1) loading all views in the background before they are requested for viewing so they load instantly on click.

and

2) Just hiding a particular set of rows rather than removing it so if the client navigates back it will be instant as well.

This would mean that potentially 10s of thousands of html elements would be loaded into the current document; is this a problem? What if it was more than 10's of thousands?

alh
  • 2,569
  • 6
  • 29
  • 42
  • Can you try firebug, then HTML tag, then right click on the element you want to check the number of elements and choose `Log Events` I know it is events, but you can do really some useful data mining from there... – Ahmed Hamdy Jan 06 '14 at 16:01
  • 1
    I am not exactly sure if loading a max of 3 x 10,000 rows would be a good idea. It looks like it can be quite slow: http://jsfiddle.net/ZcGJF/ – Chi Chan Jan 06 '14 at 16:10
  • Possibly related: http://stackoverflow.com/questions/4365741/javascript-performance-problems-with-too-many-dom-nodes – Robbie JW Jan 06 '14 at 16:57
  • 1) Always lazy/partial load. 2) Identify your target devices, and build out a sample and learn your device limits. 3) Recognize *what* causes the bottleneck; processing 10K elements in a tree probably isn't a big deal, but sizing/drawing them can be. Optimized CSS/HTML/JavaScript can help. 4) Try to work around device limits with UI tweaks (better filters for data, caps on max number of records, removing elements that are older (e.g. a few clicks back) while keeping newer ones, clear loading indicators when the user has to wait, etc.) – Tim M. Jan 11 '14 at 08:22
  • This seems to me a very subjective question, “What if ______ happened?” Loading any kind of document into any kind of software requires some memory, the performance of said load depends on the hardware power and how efficiently the software can load or present the document etc. In the case of HTML documents, what browsers and what hardware are you asking about? Are the elements you're loading in the page going to have javascript events bound to them? etc. etc. There are just too many variables to truly answer this question as asked. – Andrew Jan 13 '14 at 04:30

4 Answers4

1

It depends on the HTML elements, but I would say as a rule of thumb, don't load upfront.

When I say it depends on the elements, I mean take a look at facebook for example. They load maybe 10 or 20 items into the feed, and then add more as you scroll, because each item is so rich in content (photos, videos, etc).

However on the flipside of that, think about how much info is in each row, if it's say, less than 500 bytes, 500 x 10000 = 5MB, which isn't an awful load for a web request, and if you can cache intelligently, maybe it will be a lot less than that.

The bottom line is, don't assume that the number of HTML elements matters so much, think about the amount of data that it amounts to. My advice, cross that bridge when you get there. Monitor your request times, if they are too long, come up with an AJAX page loader, which shouldn't be too hard.

OneChillDude
  • 7,856
  • 10
  • 40
  • 79
1

Loading 10000+ HTML elements onto your page is not a very smart idea. If the user's computer is of normal to fast speed, the user may experience slight lag, and if the user's computer is slow, it may even cause a system crash (depending on the amount of RAM on the computer).

A technique you could explore is to lazyload the HTML elements - this means that when the user scrolls down to a particular portion of the page, then the elements are loaded via AJAX. (also known as "infinite scrolling").

This means that the browser's rendering engine does not have to render so many elements in one go, and that saves memory, and increases speed.

Lucas
  • 16,930
  • 31
  • 110
  • 182
0

The size of your html document would be conciderable... I once got a page with 5000~10000 items (table rows) and the browser (IE) was rendering way too long (downloading the page, parsing and rendering it).

The best solution seems to me to set up a WebService with a LazyLoading system.

So IMHO yes, the number of element in a HTML document should be monitored.

cubitouch
  • 1,929
  • 15
  • 28
-1

Yes of course! The number of element in a HTML document can be monitored.! Use FireBug in Firefox! enter image description here

Shreejibawa
  • 1,860
  • 1
  • 25
  • 35