4

So I've discovered some peculiar behavior in Google Chrome today.

When you place a table which contains tens of thousands of rows within a fixed height div (forcing it to scroll when there's enough data), it scrolls realllly slowly. With 10,000 rows it's pretty sluggish, with 100,000 rows it's almost unusable. However, on Firefox and IE the table scrolls normally no matter the amount of data.

I've made a plunker for your quick viewing pleasure. You can adjust the amount of data that's generated and see for yourself how the browsers respond.

https://plnkr.co/edit/3jvTtbk6B837uJsXiP2e?p=preview

It is also important to note that this is not an issue when the div is allowed to extend past the edge of the screen. It's only when the max-height and overflow: scroll CSS properties are set on the div that this happens.

Has anyone else experienced this? Is this a known issue? Thanks!

EDIT: clarity

elliotwesoff
  • 188
  • 2
  • 11
  • Opening this in Firefox and Chrome does not give me a noticable performance slowdown in Chrome… – Ward Segers Aug 25 '17 at 13:55
  • 1
    Browsers have never been designed to display 100k rows because no serious site will ever display 100k rows on one page. It's as simple as that. It's like you try to plough a field with a Ferrari, and you come here saying "Hey guys, that's funny, I found out a Ferrari sucks at ploughing a field" – Jeremy Thille Aug 25 '17 at 13:58
  • 2
    I like auto-mobile analogies :p – Jaromanda X Aug 25 '17 at 14:01
  • Don't use Plunker for that amount of data, it uses an iframe for output which requires additional instance of the browser. No Plunker, no iframe, no issue. The table in it's own html file doesn't have any issues. – Dmitriy Kravchuk Aug 25 '17 at 14:41
  • 1
    @DmitriyKravchuk, the issue doesn't exist when you open the Plunkr in Firefox. – elliotwesoff Aug 25 '17 at 15:18
  • @JeremyThille, I understand that, but I'm writing a web application that's going to be embedded in a C++ application, and it is possible that this table could be loaded with tens or even hundreds of thousands of rows. – elliotwesoff Aug 25 '17 at 15:20
  • checkout slickgrid, 10000 should be OK, but 100000 is really not so few – Martin Meeser Feb 28 '18 at 20:52

6 Answers6

13

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

Sebastian
  • 5,721
  • 3
  • 43
  • 69
  • Hmm that's really interesting. I have been able to fix the scrolling speed in an example table I made by using that transform property, however it doesn't make much of a difference on my production app (which is where it actually matters!). Good to keep in the back of my head though, thanks. – elliotwesoff Oct 18 '17 at 13:13
0

Well, the website can become sluggish if there are many DOM elements.

For this, you could try some virtual scroll plugins, like this one - https://github.com/tbranyen/hyperlist

Haven't really tried this specific one, but in theory it should help

SpeekaDievs
  • 312
  • 2
  • 12
  • 1
    That shouldn't be the problem either. If you open the DevTools and go to the CSS and deselect the `overflow: auto` property, the div is allowed to stretch past the end of the screen and performance becomes normal. – elliotwesoff Aug 25 '17 at 15:13
0

It's a problem is the browser itself (It doesn't support smooth scrolling by default).

Here is an article on how to enable it on Chrome manually How to Enable Smooth Scrolling Feature in Google Chrome?

and you can use @SpeekaDievs plugin to achieve this programmatically

Monir Tarabishi
  • 716
  • 1
  • 16
  • 30
0

Overflow is causing the delay in scrolling. In your stylesheet, change this:

div {
  max-height: 700px;
  overflow: auto;
}

To this:

div {
  max-height: 700px;
}

If you decide to keep the overflow, there's no way around the sluggish issue.

Dmitriy Kravchuk
  • 476
  • 4
  • 16
  • It's not an iframe issue. Plunkr may be using an iframe to embed the example, but if you save it locally and open it with chrome via "Open..." it will do the same thing. – elliotwesoff Aug 25 '17 at 15:11
  • Not for me. It's either JS issue then or insufficient resources. Did you save the file in my answer and opened it? And you're still having the same issue? – Dmitriy Kravchuk Aug 25 '17 at 15:15
  • Yeah, the problem doesn't exist in the HTML file you provided because there isn't any CSS. It only happens when the `max-height` and `overflow: scroll` properties are enforced. I guess I could make that more clear in the initial problem description... – elliotwesoff Aug 25 '17 at 15:17
  • Sorry, completely changed the answer. Make sure the HTML is not in an iframe e.g. Plunker, and remove the overflow which causes your performance issues. – Dmitriy Kravchuk Aug 25 '17 at 15:21
  • Removing the overflow causes the div to ignore the max-height property, allowing the data to extend past the edge of the page, thus fixing the issue. BUT I need the div to be a fixed height and have the data scroll smoothly inside of it. – elliotwesoff Aug 25 '17 at 15:27
  • Not sure what could be the workaround. Having it in an iframe without overflow will cause exactly the same issue, so that's not an option. Looks like anything with an additional scrollbar for the table will set you back. Other browsers have different code bases, so their performance with this might differ. So to me it looks like Chrome performance issue with overflow elements and not JS/HTML related issue. – Dmitriy Kravchuk Aug 25 '17 at 15:37
0

I tried this with Chrome 64 and it removed the scrolling issue:

<div id="extra_div" style="overflow-y: scroll;">
    <table style="table-layout:fixed">
       <!-- table-layout fixed is required, not tested if it affects the solution. -->
       <!-- a table with exactly 1000 rows, already sluggish without outer div-->
    </table>
</div>
Martin Meeser
  • 2,784
  • 2
  • 28
  • 41
0

A bit of a late entry but I had a similar issue here with a way smaller table. It turned out I had hardware acceleration disabled in Chrome. After enabling it again everything works smooth.

Arno van Oordt
  • 2,912
  • 5
  • 33
  • 63