[Feature Request] Table rendering is too slow when 1000 records (hopefully you can support scrolling according to scroll bars)

[yangcan1930]

Existing Component

是

Component Name

table

Description

背景：由于业务限制，用户希望直接用滚动条就能滚动所有数据。
现状：在1000条记录的情况下，表格基本卡死，操作卡顿很厉害；自己尝试通过滚动事件解决，但是由于滚动条是在表格内部，所以很难处理。
期望：可以根据总的记录条数做一下滚动加载，目前应该有不少类似的方案可以参考。
目前我们项目完全基于element UI来做的，各方面都很好用，只是目前遇到的这个问题比较严重，会影响到产品的交付。
期望能得到回复吧，谢谢。

[element-bot]

Translation of this issue:

Existing Component

yes

Component Name

Table

Description

Background: because of business restrictions, users want to scroll directly to all the data directly.

Status: 1000 records in the case, the basic form death card, operation Caton very powerful; try to solve through the rolling events themselves, but because the scroll bar is in the form of internal, so it is difficult to deal with.
Expectations: according to the total number of records to do rolling loading, there should be a lot of similar programs, you can refer to.

At present, our project is entirely based on element UI to do, all aspects are very easy to use, but this problem is encountered more serious, will affect the delivery of the product.
Expect a response, thank you.

[jialuchun]

select数据特别多时，切换路由特别慢

[Ray-56]

me too, Did you solve it
你的解决了么

[xeoshow]

我们也是类似问题，滑动特别卡，切换路由也极慢。目前项目完全基于element UI来做的，解决方案也和楼主的期望一样。已经影响到产品的交付。

甚至因为这个，不得不在其他框架如iView啥的做对比研究。真心期望可以尽快解决，我们也升级到elementui 最新的2.0.8版本了。

[xeoshow]

以前记得有virtual scrolling技术，可以大大加强巨大数据量下的表格性能，比如slickgrid之类:
https://github.com/mleibman/SlickGrid

这是slickgrid在极大数据量下的表现：
This page demonstrates various techniques for optimizing DataView performance for large client-side datasets. This page displays an interactive grid with 500'000 rows with real-time filtering.
https://6pac.github.io/SlickGrid/examples/example-optimizing-dataview.html

如果elementui可以把这个技术吸纳融合进来，就完美了！

[fengyuyizai]

我也遇上这方面问题，项目基于elementUI，但table在处理大量数据时滑动卡顿

[zhaoshaomeng]

table数据量大，渲染的慢

[lu0371]

同样的问题

[dumbdonkey]

I have met this problem too.

[KristenXu]

同样的问题

[Ray-56]

2.0 版本解决了这个问题么?

[DomenicRoti]

I'm also having a problem with table performance, I have a page with about 5 tables (though not with a huge amount of data in each table), the time it takes on slower devices like tablets is unbearable.

I wish I could just have a loader inside the table so that the user knew something was happening, instead the whole page freezes while it tries to render all of them.

[mclaran]

I see the problem is still not solved since last summer?

[DomenicRoti]

It is a problem, the table is generally not very perfomat. My band aid was to add a loader to the page, and a settimeout then add in the tables. It's not great, but I imagine in the future I'll have to just ditch the tables and write my own component when I get the time.

[mclaran]

there are several solutions, such as "vue-virtual-scroll-list". Why not make the component "el-table" according to a similar principle? After all, it does not load.

[DomenicRoti]

I have experienced no problem with scrolling, I have seen serious lag though on older/slower devices (including mobile/tablets) in just loading a page with multiple tables on it. Once it loads, I have no issue, but the whole page freezes up as the component (presumably) figures out what to render.

[mclaran]

Due to the growth of the project, and based on customer feedback, it was decided to move from a page to an endless download. We have a very complex table. Scrolling was very slow when the number of rows was 200. And the number of such lines can reach up to 5000 and even 10000. Measurement in devTools showed that the critical problems are associated with "el-table", too much time is spent on the recalculation of the lines (reached the wait up to 5 seconds). That's a lot. Therefore, the only way out was to use virtualization and remove elements from the DOM out of sight. The result on the face: the maximum wait was 3 ms.

[ruiyong-lee]

只要列多，200行都会很卡顿

[348251248]

Any solutions for this?

[ruiyong-lee]

使用transform: translateZ(0);可以解决滚动卡的问题，但是如果列表多了，多选框选中反应依旧很慢
而且开启左右列固定的话，就相当于渲染了3个表格，bodyWrapper使用transform: translateZ(0);是没什么问题，但是fixedBodyWrapper和rightFixedBodyWrapper的scrollTop是在bodyWrapper的滚动事件中去设置的，这里我暂时想不到用什么方法优化

[patie]

checkbox checking in table is also very slow when there is more than 100 rows, its possible to do something with that?

[wangshuai0]

题主解决了吗？

[szhjia]

超过2年的issue，有点说不过去了……

[doutatsu]

I've noticed that it's extremely slow even with a couple of hundred entries, I didn't realise how unperformant this component is. I am surprised this is not a priority to be fixed. Will have to find an alternative until this is fixed. Or use pagination, even if locally... Anybody got a good Vue table library?

[IssueHuntBot]

@doutatsu has funded $5.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[doutatsu]

Has there been any progress on this at all? I'd fund it more if that would make it a higher priority...

[peterlyq]

the same question

[bacy]

i am glad that i am not alone

[vikashpisces]

Due to the growth of the project, and based on customer feedback, it was decided to move from a page to an endless download. We have a very complex table. Scrolling was very slow when the number of rows was 200. And the number of such lines can reach up to 5000 and even 10000. Measurement in devTools showed that the critical problems are associated with "el-table", too much time is spent on the recalculation of the lines (reached the wait up to 5 seconds). That's a lot. Therefore, the only way out was to use virtualization and remove elements from the DOM out of sight. The result on the face: the maximum wait was 3 ms.

Can you provide the solution you applied to fix this issue? May be that can help many of us who has navigated till here while looking for solution.

[yangjunjun]

please use vxe-table, which is more powerfull and highly efficient (which use virtual scroller method to solve mass data problem). And Its API very similar to a el-table, migration is easy.

请使用 vxe-table ，它更强大而且性能更好(使用了虚拟滚动技术来解决大数据量的问题)。而且它的接口和 el-table 很相似，代码迁移过去也很轻松。

[ray007]

I've added virtual scrolling for my own use from the outside, which is not too hard if you can assume a fixed row height.
Downside is that all operations requiring el-table to have all row data do not work anymore (local sort and filter, summary, ...).

It would probably also help performance if the tables for the fixed columns didn't include hidden cells for the non-fixed columns.

Is anyone working on this?

[zl7261]

的确十分卡，不用到9999那么多，千来条就明显了，如果table里有其它元素，如input，日期选择，百来条也卡。看了一下row-class事件，表格在鼠标hover时，会计算所有表格。其实可以加标记，hover 不要计算那么多。

既然这样,加个scroll的监听器,给el-table加个pointer-event:none,也是一个解决办法,scroll的情况下,确实应该不触发hover

没仔细看源码,但是按这个思路试验了下,在滚动条上面滚动,是不怎么卡的,
在table-cell上面滚动就卡的厉害.

[ganl]

table套table 外加fixed 卡顿更明显，五十条就卡了

[saidrahmani2000]

I faced the same issues, i have 100 tables in page with some input action to change table value.
Any solutions for this?

[DaTongDXM]

2021年了，还是很卡

[lipengzhou]

2021年了，还是很卡

+1

[Corchoneitor]

2021年了，还是很卡

+1

[neilguangzhou]

2021年了，还是很卡

+1

[govo]

AV8D try this for large data rows:
https://tangbc.github.io/vue-virtual-scroll-list/#/

[orenmizr]

anything about his virtual scroll in element plus for vue3 ?

[shixiaobao17145]

还是很卡。。。

[guanguosl]

2022年了，还是很卡

[KristenXu]

谢谢您的来信，我会尽快给您答复。 (许琛)

[wuvpeng]

2022年了还是很卡，el-table 套 el-select，100条数据，卡得不行

[KristenXu]

谢谢您的来信，我会尽快给您答复。 (许琛)

[ganl]

2.15.7 有个table性能优化，结果引入一堆bug。 2.15.10 不知道修完没有

[KristenXu]

谢谢您的来信，我会尽快给您答复。 (许琛)

[kiosk123]

when el-table's column 100+, el-table very slow render... so Do you have any solution?

[lizhen789]

同楼上，列数过多时，也是卡的要死，正在找解决办法

[KristenXu]

谢谢您的来信，我会尽快给您答复。 (许琛)