Fix scrolling performance outside of table

[cubiclesoft]

Using the latest minified version, there's a major performance problem while scrolling in Firefox when a table only has just a few hundred rows of data. I figure around 200 rows is the point where this plugin becomes handy. IE also seems to be mildly affected but to a lesser extent. Google Chrome seems to be completely free of lag. Here's a Fiddle that demonstrates the problem:

http://jsfiddle.net/stFcx/2287/

Scrolling above and below the table in Firefox has some pretty significant lag. However, all of the lag vanishes whenever the table headers start tracking within the table itself. Removing the plugin also makes the lag vanish. The problem seems to become more prevalent as more rows are added to the table, which is why this bug doesn't appear in the official demo for this plugin.

[jmosbech]

Thanks. I heard about this before but haven't gotten around to look into it. I'll dig in as soon as I have some free time.

In the meantime I suggest you try to use one of the older versions. I suspect this was introduced recently.

J

[glenn-murray-bse]

+1 for this bug

Laggy in firefox while table header re-positions, noticeably smoother once fixed position. Smoother in chrome and IE but still laggier than without plugin.

[gamov]

yes indeed. I'm on the same boat. I'm on an older version because of that. See here: https://github.com/jmosbech/StickyTableHeaders/pull/60

[glenn-murray-bse]

@gamov can I ask which version you are using? I might see if it works for me

slightly off topic, but I think I'll use a different solution due to the sticky header not refreshing until scroll events (which don't get fired on mobile touch move events)

[gamov]

@glenn-murray-bse As stated in the referenced pull request: 0.1.6

[webdaily]

I've tried using way back to 0.1.11 and IE is still VERY laggy at the point the header is initialized. Once it is on the page the scrolling is fine however until that point (even before the the offset is reached) it is very jerky. Chrome works with no major issues. Is there a fix for this?

[hornj]

Any chance of a fix for this? I've been using this on a web app that at times contains pretty huge tables. I can accept a bit of lag, since it is a pretty massive table. But on Firefox it freezes for about 1 second when the sticky header is being enabled or disabled, which isn't acceptable performance for us.

Thanks!

[cubiclesoft]

@hornj I've been eyeing floatThead as a possible alternative sticky table header solution for quite a while: http://mkoryak.github.io/floatThead/

When I first found floatThead, my initial tests showed that it was capable of easily handling thousands of rows of tabular data without the lag issue seen here. If you end up using it, please let me know how it goes.

[cubiclesoft]

I recently attempted to use floatThead as a replacement StickyTableHeaders and it was more or less a disaster. The headers were all over the place. I think part of the problem might have been the use of a jQuery UI Accordion, started collapsed. I ended up going back to StickyTableHeaders even though this bug still exists. Your mileage, of course, will vary.

Another alternative I ran into yesterday is a fork of jQuery tablesorter: https://mottie.github.io/tablesorter/docs/

Even though it has sticky headers, it also has pagination, filtering, and AJAX support (along with combinations of those). Depending on the use-case, instead of displaying thousands of rows of data display only some rows of data and use AJAX to fill in the rest. That's not really a solution for me for the general case when I need sticky headers, but it's nice to know that it exists.

[stewardo]

floatThead solved my problem with Firefox lags http://mkoryak.github.io/floatThead/

[cubiclesoft]

Another problem I ran into with StickyTableHeaders is specific to Android Chrome. The bug is intermittent and is caused by updating "too frequently". Basically, when the headers are supposed to start scrolling, they don't, and when the headers are supposed to stop scrolling they also don't stop. This leads to some pretty wild visual artifacts. The issue occurs when doing "too many" UI updates inside a setTimeout() or setInterval() callback with "too many" being as little as one DOM change. requestAnimationFrame is supposedly the "correct" solution, but even that can trigger the bug. The behavior is intentional in Chrome on Android to improve user experience when scrolling and the Chrome Developer Tools console emits a message that refers to this specific bug report:

https://bugs.chromium.org/p/chromium/issues/detail?id=574343

StickyTableHeaders is kind of broken on Android thanks to Chrome's aggressive scheduling mechanisms that prevent setTimeout(), setInterval(), and sometimes requestAnimationFrame from executing in a timely fashion while the user is scrolling the page.