Slow Response When the HTML Table Is Big

Slow response when the HTML table is big

The first thing that is slowing your loop down is .insertRow(). You're doing this at the top of your loop and then adding cells to it. After the row is added, and after each cell is added, the browser is doing layout calculations. Instead use .createElement() and then .appendChild() at the end of your loop.

Demo: http://jsfiddle.net/ThinkingStiff/gyaGk/

Replace:

row = tableContent.insertRow(i);

With:

row = document.createElement('tr');

And add this at the end of your loop:

tableContent.tBodies[0].appendChild(row);

That will solve your loading speed issue. As for the hover, you have way too many CSS rules affecting your tr and td elements using tag selectors. I removed a few, and used classes on a few, and the hover highlighting is much faster. Specifically, I noticed that overflow: hidden on the td elements slowed it down considerably. Consider combining some of your rules, using simpler selectors, and adding classes to elements for quicker CSS processing. During hover many things have to be recalculated by the the layout engine, and the fewer CSS rules the better. One example I saw in your code was #tables tbody tr when there was only one tbody in the table. #tables tr would have sufficed. Better than either of those is a class. I used .row in my demo.

Best practices from Google Page Speed:

• Avoid descendant selectors: table tbody tr td
• Avoid redundant ancestors: body section article (body never needed)
• Avoid universal (*) selectors: body *
• Avoid tag selectors as the key (right-most): ul li
• Avoid child or adjacent selectors: ul > li > a
• Avoid overly qualified selectors: form#UserLogin (# is already specific)
• Make your rules as specific as possible (class or id).

Large HTML tables are slow to scroll in Chrome

I can confirm your observation: Looks like IE and Firefox are doing some optimized rendering (presumably by using the hardware acceleration) but Chrome isn't.

And I have to disagree with other answers, stating that you simply must use smaller tables, because the Chrome slowdown comparing to other browsers is observable with even smaller tables with only a few hundred rows but more complex content.

You can force Chrome to use optimized rendering here by using

transform: translate3d(0, 0, 0);

See Sluggish scroll behaviour of large(ish) html table in Google Chrome

Switching between inputs is slow in a large HTML table

I did some more digging and testing, and it turns out the lag (update layer tree) when clicking/typing in inputs is only an issue in Chrome. This answer on another question points to issues with Chrome since version 46. It's a shame that such a popular browser has allowed an issue like this to go on for 2+ years. We will have to paginate our order form since Chrome is so popular with our client's customers.

Slow rendering of HTML table when binding JSON data

Here are some performance stats:

with contenteditable (~4000 digest calls) = 1.800ms -> http://prntscr.com/lweugn

without contenteditable (~4 digest calls) = 1.300ms -> http://prntscr.com/lweusn

with pagination just showing the first 50 results = 0.200ms -> http://prntscr.com/lwev09

You loose the most performance because of the DOM changes obviously. But keep in mind that the number and duration of digest cycles is key for good performance. Especially when you have a huge amount of watchers. Here is a Direct comparison:
http://prntscr.com/lwf1nn As you can see the digest loop is burning 30% of your performance overall but is not the reason for your frame drop. The frame drop is mostly caused of the DOM changes. Drawing such a big table takes some time.

Further the table starts rendering when your REST call is finished. This call takes in my case roughly additional 1.700ms. So it takes nearly 3.500ms from start until rendered results. Even with pagination 1.900ms.

I would recommend a pagination with search but you can try to increase the performance anyway.

Helpful links would be:

https://stackoverflow.com/a/47347260/8196542

https://www.codeproject.com/Articles/1173869/%2FArticles%2F1173869%2Fng-repeat-performance-degradation-at-case-of-very

---

Related Topics