又来请教前端大佬们了

[supuwoerc]

小弟今天接到一个性能优化的任务，任务如下：

vue+element-ui 的项目，里面有一个表格，表格是树状可展开的，展示的是组织架构。

数据接口在后端的高强度优化下已经到了 1 秒左右，前端递归处理数据格式也优化过了，但是现在页面还是十分卡顿，从 dom 分析看来是 dom 太多导致的，浏览器在任务管理器面板看占的内存达到了 3.4G 。

谷歌了相关方案，大多数是插件和虚拟列表的思路来处理，插件我 github 找了俩，尝试过发现内存依旧不变，并且有别的问题，遂放弃，虚拟滚动思路我看了几篇文章也清楚了，但是问题是我的页面是树状的，并非一个单纯的列表。

虚拟列表的思路：监听滚动位置，根据滚动量在数据中切割出应该显示的部分数据再放到模板里面来渲染，貌似不适用 =。=||

遂来到 V2 请求大伙的帮助。

感谢大家~~

[SilentDepth]

如果每个节点的高度相同，把整个树看作是一个由节点组成、每个节点的 margin-left 不同的列表，也许可以再尝试应用 DOM 复用的模式？

或者直接渲染成 Canvas （

[3dwelcome]

用 SSR 啊，学 memcache 做中间层缓冲，用 websocket 实时响应客户端的树状结构点击展开事件，然后把 DIFF 部分塞入 DOM 返回给前端。
直接无脑把 3.4G 的数据放到客户端，不卡才怪。

[fishlium]

数据不要放到 data 里面，或者试下 object.freeze(),虚拟滚动的问题你可以把树展平，通过样式去展示成树

[kop1989]

我想了想，从你的内存看，数据量确实有点太大了。

1 、业务上有没有妥协的余地？比如改成分页取数，或者退一步，数据一次获取，但页面分页滚动的形式。（总体上就是在可控的情况下削减数据量+dom 渲染数量）。

2 、根据树的展开情况+滚动位置，动态添加删除 dom （也就是你说的“虚拟滚动”）。我思考了一下，好像树状也不影响动态 dom 控制，只不过相对比单纯的 list 逻辑复杂一些。（要考虑树的展开状态与滚动条高度之间的逻辑关系，以及处理好展开、合并时的显示逻辑）

[codermagefox]

这东西就不该在前端优化。
做成异步获取才是正道。

[NMmmm]

element 的 tree 不是有动态加载嘛

[waiaan]

试试懒加载，dom 太多了，要展示的才加载 dom 。

[codepark]

先展示主干, 自己想看哪个分支再点哪个分支多好~

[Vipcw95]

应该是数据太多。用 pl-table 这个库。可以动态加载数据

[gy134340]

给我打款 500，我来帮你优化

[echol]

#1 已经说了
这是设计问题
允许的话节点的展开做成下钻
数据异步是另一方面的问题了，变化不大