在浏览器里展示大量表格数据

HTML 是显示类似表格数据最常用的方法，这很合理，因为 HTML 提供了全面的格式化模型，避免你重复发明轮子。

这篇文章主要是为那些因用户界面表现不佳而被暗中评判的技术负责人。：）不能更直接了

虽然这很令人满意，但在展示大量数据时，可能会遇到一些问题。

• 大量的DOM节点可能会影响性能
• 大量的DOM节点，可能会带来明显的重排开销。

你和你那台高端的Macbook M3笔记本可能不会感到痛苦，但对于使用低配置设备的人来说，这可能会是一次很糟糕的经历。

在某个时候，每个拥有流行网页应用的大型软件公司都会要么艰难地，要么轻松地发现这一点。然后会有一个会议，与设计师和前端开发人员讨论，从而产生等等结果。

• 减少DOM节点并优化昂贵的CSS规则
• 尽量限制或消除动画
• 限制或禁止用户的滚动功能

大型的HTML项目面临许多限制，作为开发者，你的性能分析工具会变得像你最好的朋友一样，

现在，你可以通过实现列表虚拟化技术来解决“DOM节点数量过多”的问题，这种方法允许你在内存中加载大量数据，只渲染用户视图相关的DOM部分，类似于视频游戏中的视域剔除。

尽管虚拟化了你的项目列表，你仍然可能遇到回流导致动画抖动的问题。让我们实话实说，HTML 和 CSS 已经是迟到的改进，但目前我们只能使用现有的工具。

我不太喜欢为了技术限制而牺牲用户体验。我们有 Canvas 2D 和 WebGL，还有即将推出的 WebGPU 上下文。这些技术的限制不是技术上的，而是从事 GPU 工作的 Web 开发者相对较少。Three.js 在这方面确实帮了点忙，但总体来说，这个圈子还是很小。

那又能做什么呢？

以前有人告诉我，他们的朋友花了2000美元买了一个网站，结果却发现那只是一个网页，整个用户界面竟然只是一张jpeg图片。

好了，别笑了 :), 我正在说的是一种前沿的UI策略。那么，这种策略在实际应用中能给我们带来哪些启示：

好的地方：

• 低节点数：图片可以减少站点上的节点数
• 减少重排：图片虽不完美，但它们的重排性能远优于嵌套的DOM树。
• 可以生成：可以使用canvas或offscreen-canvas通过BlobURL即时在浏览器中生成图片。
• 低内存：jpg、png、webp和avif等格式的图片占用的内存比它们替代的任何数量的DOM节点都要少。它们占用的内存也比Canvas接口少。
• 浏览器相关

不足：

• 不具备互动性
• 访问性不佳
• 不能选择数据
• 需要高分辨率来适应不同设备的像素比或缩放

视情况而定，您可以从PlayStation 1时代开始，通过禁用双线性纹理过滤并使用CSS中的图像呈现属性image-rendering来实现像素化。

CSS 3D 变换创建了合成层，以流畅的 GPU 速度渲染 DOM 层。唯一的问题是它并不能完全避免在所有情况下发生重绘，并且在静止时有时会导致较差的渲染质量 (我们对它在移动时的状态并不在意)。

但你可以利用这个策略，在数据移动时，用一个假的复合层来替代那些大量的表格中的数据。

• 利用 offscreen-canvas 获取并渲染数据： 原生的 canvas 并不难掌握，前提是理解 canvas 上下文具有状态属性。你也可以使用类似 html2canvas 的工具（该项目已不再维护）。
• 将 canvas 渲染成图像： 使用 BlobURL 替换复杂的 DOM UI 为图像，就像一个完整的骗局 :)
• 互动的 DOM 覆层： 你需要创建一个 UI 来覆盖当前可见的数据部分，以表示这些在视图中的数据。该覆层应在动画或滚动过程中淡出，然后在转换完成后重新显现。虽然覆层的 HTML 应该看起来像图像数据，但并不需要完全一致，因为实际图像主要在调整大小、滚动或动画时才可见。

这当然取决于情况。对于一般规模的数据来说，这种方法显然过于复杂。对于常见应用或统计报告，我强烈不建议使用这种方法。

仅在你遇到性能问题时使用此方法，但也要考虑图像大小的固定值。

说你有 10 张 AVIF 图像，每张图像的尺寸为 2000 x 1000 像素，用于你的数据流场景。尽管经过压缩，每个图像仍会占用大约 8 MB 的内存，总共将占用 80 MB 的堆内存（BlobURLs 通常存储在堆中）。相比之下，等效的 DOM 节点会占用更小的内存，可能只有大约 1 MB。

在上述场景中，将会产生 80MB，而不是通过 HTTP 下载。考虑到这一点，像 Instagram 和 Twitter 这样的流行应用程序在图片方面远不止这些。

这比列表虚拟化更有野心，更雄心勃勃，在某种程度上，它也是一种列表虚拟化。最终效果应该让用户感觉非常流畅，同时让用户感觉成千上万甚至数百万的DOM节点在页面上快速移动。

将其视为“Nanite for HTML数据的”但更ABC，可以把它想象成“Nanite for HTML数据的”，但更ABC。

朱利安 (Zhū Lì'ān)