Semantic-ui: [Table] Tables with lots of rows (200+) and columns (20+) are very slow to scroll

[jprateragg]

We're using 2.2.13 of the framework primarily on Windows 7 and IE11. We have a very large report our application generates. It contains over 20 columns and over 200 rows. Scrolling up and and down the table is incredibly sluggish. Doesn't matter if we're using the scroll wheel on the mouse or dragging the scroll bar on IE, it's just incredibly slow and sluggish. Works fine on Chrome though, but we're not using Chrome unfortunately.

[awgv]

Hi @jprateragg, what’s in your table’s tds?

[ZoeDreams]

This is a known issue with how IE processes td cells and tables in the DOM. One thing you could try to do is to make multiple tables and style it to look like its one table.. i would try that first and see if you squeeze out some performance with the dom rendering. You could also experiment with not using a table, and div's instead. Could also run the performance monitoring tool in the dev tools to see if there are any bottle necks with some javascript slowing the page when scrolling. https://msdn.microsoft.com/en-us/library/gg699341(v=vs.85).aspx Just some ideas.. good luck

[jprateragg]

@Banandrew Here is an example of a row:

<tr hovertext="">
    <td>8</td>
    <td>001</td>
    <td><a href="#" rel="shadowbox;width=800;height=800" title="CUSTOMER">CUSTOMER</a></td>
    <td>&nbsp;</td>
    <td>1234567-123</td>
    <td>0.00</td>
    <td>478,932.70</td>
    <td>9D</td>
    <td>130.96%</td>
    <td>46.50%</td>
    <td>246.41%</td>
    <td>47.17%</td>
    <td>11</td>
    <td>011/SMITH</td>
    <td>012/BROWN</td>
    <td>013/THOMAS</td>
    <td>014/JONES</td>
    <td>&nbsp;</td>
    <td>None</td>
    <td>9/6/2017</td>
    <td>SUB</td>
    <td>3.45%</td>
    <td>(040) Poultry</td>
    <td>78.60%</td>
</tr>

Sometimes there will be something in hovertext, but it would just be 20-50 characters at most and no JS functions or anything.

[jprateragg]

@1-14x0r I will try breaking it up into multiple tables and see if that makes any difference.

[jprateragg]

@1-14x0r I divided up the report into separate tables as you suggested. I grouped it by regions, and we have 20 regions in our organization, therefore 20 tables. The performance is better, but, but definitely not great. The scroll bar on the browser works much better, but scrolling using the mouse wheel still freezes a bit. But definitely better than one large table.
I may format it using divs instead, but that will require me to completely redo the report which I'd like to not have to do. Thanks for your help!

[awgv]

@jprateragg If you’re using the .celled class with the table, try removing it and see if it makes the performance better.

[jprateragg]

I removed the celled class and performance was about the same--still just as sluggish.

[awgv]

@jprateragg Just to make sure, is there any difference if you use the default tables without SUI? Try removing SUI’s classes from the table tag.

[ZoeDreams]

also do you do any of the cell clip large content? see http://connect.microsoft.com/IE/feedbackdetail/view/968689/ie-11-extremely-slow-scroll-performace-in-tables-with-cell-clipping

also have you tried to experimenting with manually scrolling content by overloading your scroll input events? Such as disable scroll wheel. see https://stackoverflow.com/questions/20026502/prevent-mouse-wheel-scrolling-but-not-scrollbar-event-javascript
then manually scroll the page with https://www.w3schools.com/jsref/met_win_scrollto.asp

my guess is that the the very large amount of td cells is causing a buffer overflow within the stack of input event events. IE being the amazing browser that it is, is gobbling up the overflow to prevent the browser from crashing. Similiar to the dreaded script taking to long error dialog... yuck. Chrome handles input much differently which is why you might not see the sluggish behavior as much. Scroll wheel has the potential to generate ALOT of scroll to events behind the scenes.. Just a thought. could be wrong though.

I also would try disabling any CSS as stated above and see how the native behavior with a very large table works. see https://stackoverflow.com/questions/10609931/how-to-avoid-the-performance-cost-of-overflowhidden

as for what your trying to do, its definitely in the realm of possible. I ran into this exact issue with GWT a few years back being forced to run the webapp in IE10 on windows xp.. ugh... The tables were 20 columns by about 500 rows, pushing anything over that was very hard. i was able to squeeze out 1000 rows using divs and some table hackery... Not only did i split the tables up horizontally i also split them up vertically.. Keeping it about 2 to 5 columns per table, and about 100 rows per table.. granted your still generating 25 to 50 tables per page... it fixed the scroll issue. I lazy rendered the tables to only render tables that are in the viewport... that is why we split up horizontally and vertically.

alternatively you could make your table as an SVG.. that might render with scroll better.. https://stackoverflow.com/questions/6987005/create-a-table-in-svg
GLHF; I really understand how troubling this can be, as i had to deal with it before..

[jprateragg]

@Banandrew @1-14x0r The way we had this report formatted previously was with some basic CSS styling and no JS. It was very simple. We recently just started switching over our reports to SUI so they were consistent with our main application (which uses SUI obviously). So, this report worked perfectly before we moved to SUI. The number of columns hasn't changed, the rows vary from month to month (still 200-300 of them), but there were no performance issues.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[ryan-nash]

I had a similar problem with tables in IE and removing some CSS rules improved the performance. The lines are referenced here. Even though these lines are about labels and checkboxes you don't have to have a label or checkbox on the page for them to slow down IE.