Element: [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]

题主解决了吗？

[1008611]

@xeoshow 受这位兄台的启示，特意尝试了slickgrid，完美的解决了大批量数据的问题。顺便总结了slickgrid的基本用法

[fengyun2]

@1008611 能贴下结合element ui库的例子吗？

[3lang3]

同样问题

[iluozhiqiang]

没法解决么？

[dasnnj]

遇到类似的问题，请问您解决了吗

[gorvitovskaya]

did anyone find any solutions for this?

[ziyoung]

以前记得有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可以把这个技术吸纳融合进来，就完美了！

table 的许多 bug 都是跟固定列有关。另外很多的 issue 都提到了 table 数据量增大造成的卡顿问题。或者按照功能，可以把 table 拆分成两类，简单的 table（保证数据量大时也不会卡顿）与带有固定列的 table。slickgrid 值得研究一下。

[mythbobo]

这个场景我也碰到了。业务需要展示大量的数据。目前iview那边有一个vue-bigdata-table的组件,但一直没人更新了。功能也不太完整。数据结构采用的二维数组。也和平时用到的业务场景不一样。所以还是希望elementui能出这样一个组件。感谢了!

[elfman]

@nailfar 大佬看你说的那么轻松，你来提交pr改一下啊

[elfman]

@nailfar 首先我不是ElementUI官方团队成员，饿了么也没给我发钱，给ElementUI解决过几十个issue纯粹是个人兴趣。其次，非大版本提升时重构代码是基础库尽量避免的事情，因为可能导致依赖它的项目不可用，尤其是table这个项目内最常用又是最复杂的组件。这个issue我尝试过解决，但最后放弃了，我看你说的那么井井有条的你也可以试试啊

[mythbobo]

两位都太激动了。淡定,都说得没错,性能的确是很不好，而且这个组件也比较复杂。。现在就看官方能不能在不忙的时候抽空优化这个组件了。主要是表单这个组件太常用了。性能问题如果不解决。的确影响比较大。

[flyinglove]

我们遇到的问题是表格渲染的速度慢， 100条数据，渲染时间需要2-3s

[buremba]

I do not understand anything in this thread, could we please switch to English?

[buremba]

Is there any interest in implementing this feature?

[ziyoung]

Is there any interest in implementing this feature?

It's still under discussion.

[edum18]

+1. had to move to another package because of this

[IssueHuntBot]

@rororofff has funded $20.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.

[dxxzst]

对于数据处理不复杂的情况，可以使用这种方法解决
For data processing is not complicated, we can use this method to solve.
https://segmentfault.com/q/1010000017202682/a-1020000018142273

[xeoshow]

@xuliangzhan 兄弟，能不能搞个示例代码出来？很多团队都困在这个问题上了... 多谢多谢

[z1o]

@xuliangzhan 兄弟，能不能搞个示例代码出来？很多团队都困在这个问题上了... 多谢多谢

https://jsfiddle.net/fx6018vu/

(非原创，来自https://segmentfault.com/q/1010000017202682/a-1020000018142273
无法配合checkbox使用，不过还是感谢那位大神提供了思路)

[dxxzst]

@xuliangzhan 对于fixed情况，会出现错行

[nailfar]

vue-element-extends 只在原表格的基础上加了一些功能，虽然可以展示海量数据表格,但是 多选还是用不了，对于一个复杂的crm 系统，复杂的表格操作完全没有帮助 。目前发现的造成卡顿的地方有 hover 样式切换， select 多选页重渲染，使用列固定，其他原因有自定义表格复杂计算 表格里使用异步请求数据等等。为此我做了一些表格上的优化，本来想提交pr，但我觉得我还是个菜鸡就算放弃了。希望element-ui 组员可以采纳

1. 表格hover 样式切换造成的频繁渲染问题： 在处理onmouse enter 和leave 事件时 频繁的触发
   this.store.commit("setHoverRow", index); 每次store 里数据变化都会 导致表格全部重新渲染，如果表格使用的左右固定列，那么将有三个表格会全部重新渲染（ ），很大的性能损耗，特别在多列多行时，表格内dom 元素有12000+（自己的项目里）；使用debounce 和 throttle 会使hover 样式会卡顿。采用dom 操作方式设置hover样式，优化代码：

table.js
methods:{
onMouseEnterRow(index) {
      this.tableBodys.map((table) => {
        const el = table.$el.querySelectorAll("tr")[index];
        addClass(el, "hover-row");
      });
    },
    onMouseLeaveRow() {
      this.tableBodys.map((table) => {
        const els = table.$el.querySelectorAll("tr");
        els.forEach((e) => {
          removeClass(e, "hover-row");
        });
      });
    },
}


computed: {
    tableBodys() {
      return this.$children.filter((item) => {
        return item.$options.name === "ElTableBody";
      });
    },
}

table template

...
 <table-body
          @mouse-enter-row="onMouseEnterRow"
          @mouse-leave-row="onMouseLeaveRow"
>
...
 <table-body
          @mouse-enter-row="onMouseEnterRow"
          @mouse-leave-row="onMouseLeaveRow"
         fixed="right"
>
...
 <table-body
          @mouse-enter-row="onMouseEnterRow"
          @mouse-leave-row="onMouseLeaveRow"
         fixed="left"
>
...

table-body.js

render(h){
return   {
...
<tr    on-mouseenter={(_) =>{
throttle(60,(index,e)=>{
        this.$emit("mouse-enter-row", index);
        // this.handleMouseEnter(index)
      })
}}
...
                on-mouseleave={(_) => {
 return throttle(60,()=>{
        this.$emit("mouse-leave-row");
        // this.handleMouseLeave()
      })
}}
...}
}

1. 使用固定列时 会渲染三个表格，但是不是所有列都需要重新渲染（is-hidden）的单元格可以不需要渲染，虽然设置了display:none 但是还是会造成一些损耗，特别是自定义单元格需要进行一些数据运算的时候
   优化代码去除隐藏表格渲染内容

                    if (this.isColumnHidden(cellIndex)) {
                      return <td />;
                    }
                    return (
                      <td
                        style={this.getCellStyle($index, cellIndex, row, column)}
                        class={this.getCellClass($index, cellIndex, row, column)}
                        rowspan={rowspan}
                        colspan={colspan}
                        on-mouseenter={($event) => this.throttleHandleCellMouseEnter($event, row)}
                        on-mouseleave={this.throttleHandleCellMouseLeave}>
                        {column.renderCell.call(this._renderProxy, h, data, columnsHidden[cellIndex])}
                      </td>
                    );

1. 表格容器 resize 造成的频繁doLayout ,可以加上 debounce 或者 throttle

table.js
resizeListener(){
...
if (shouldUpdateLayout) {
        this.resizeState.width = width;
        this.resizeState.height = height;
        // this.doLayout();
        // this.throttleUpdateLayout();
          this.debouncedUpdateLayout();
      }
...
}

除此之外还可优化业务代码，比如计算结果缓存，异步处理大量复杂计算数据

[govo]

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

[nailfar]

最近提交了一个 pr 优化 第二点没有优化，因为行高度的问题会让固定列无法对齐。其次使用render 函数的同学还可以使用throttle 减少频繁的没必要的render 触发，比如封装了业务表格，在生命周期 mount 会触发一次render ， 传入默认检索参数会触发一次render 设置分页默认值触发一次render,接口请求数据到达会触发一次render ， 这四次render 对用户来说 只执行一次即可 但是vue 的响应式机制，每次的数据变化都会造成render触发，可以使用throttle 减少render 执行次数。本来要渲染 4次render* 表格列数表格行数3个表格，throttle可以减缓 镇痛。性能优化只能一点点积累，病来如山倒, 病去如抽丝。

[sunxingchen1995]

table的渲染确实有点问题，我的项目用了固定列、表格多选，并且绑定了事件，点击行会选中该行。
我还有个事件是双击打开业务功能弹窗，然后现在用户反映体验非常差，弹窗明显卡顿。
后来试了一下，选中、取消行会触发table重新渲染（双击我会触发一次选中和一次取消选中）打开、关闭弹窗，触发窗口尺寸改变事件，也会触发table重新渲染，另外由于我使用了fixed固定列，会使表格每次渲染次数*2，因此我打开一次弹窗，会触发：2（选中行）+2（取消选中行）+2（打开弹窗窗口尺寸变化）=6次的表格渲染，而我表格的几个列有一些的判断条件，所以难怪这么卡顿.....

[buremba]

I would be willing to fund $100 if someone wants to implement virtual-scroll to el-table via Issuehunt or a similar platform.

[xlz26296]

@buremba This may not be easy to achieve, you can refer to this to support virtual scrolling,horizontal and vertical support. vxe-table

[buremba]

@xlz26296 I really like that vxe-table is feature complete and the API is (partially) compatible with el-table but installing a 75kb library (minified) for a table component is really an overhead to us. Also, you may want to focus on the English version of the documentation. 😬

[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?