最近，我一直在阅读并尝试有关优化浏览器布局事件（不是绘制或复合）的不同内容，但确切地说是布局。
我正在使用的测试应用
我有一个非常简化的类似社交媒体的应用程序，它只显示用户的一些个人资料信息和一个墙贴列表（每个都有 2 个答案，向右缩进）。你可以在这个沙箱检查它的代码。我建议在这里的整个浏览器窗口中查看应用程序本身。最初呈现 1000 个墙贴，单击页面底部的显示更多将添加另外 1000 个，并且 DOM 元素计数将与以下测试中使用的计数相匹配。您可以在第 79 行检查 fakeApi.js 中新渲染的墙贴的步骤，但必须至少加载2000 个墙贴以匹配测试中的环境。有一个评论框，点击后会出现在墙贴下方----回复----对于给定的帖子。
我的目标
我想在输入评论框时减少相当大的 DOM 树的布局/更新层树时间（一次只显示一个，在给定的墙贴下方），但我现在想在不使用虚拟化的情况下进行优化。
设置
- 机器 CPU - Intel Core i7-6700HQ@2.60-3.50Ghz 的移动版本（在笔记本电脑上）
- DOM 元素 ~ 45k
- 浏览器 - Chrome 80.0.3987.163
- 前端技术栈 - React，仅适用于 CSS 的 Bootstrap，纯 CSS
测量结果
打字时间范围的性能时间表和甜甜圈图
正如您在性能时间线中看到的，当在评论框中输入几个字符时，会出现Layout（黄色下方的紫色表示按键事件），然后是另一个紫色块 - Update Layer Tree。时间，每一个按键：
- 布局 ~ 12ms
- 更新层树 ~ 21-22ms
- 打字时的平均 FPS - 20FPS
我为优化尝试过的事情
- React 方面，该应用程序已经使用shouldComponentUpdate 和 React.memo进行了优化（针对功能组件）
- 删除了按键事件处理程序甚至整个处理程序中的e.target.innerText引用
- 对自定义 CSS使用BEM 方法（在 assets/Site.css 中），保持选择器简单，1 级
- 评论框使用绝对位置
- 删除一些文本节点（减少了大约 20k）
- 删除了整个引导 CSS 包（当然，应用看起来不太好）
- 删除了所有图片
- 使用will-change: 转换评论区以将其提升为单独的布局层，但仍然层指标显示整个 DOM 层（滚动层）也在输入时更新。
类似应用案例研究
当然，Facebook 是我能想到的最接近的。我为它记录了一些统计数据，在带有新闻提要的主页上，我向下滚动，这样 DOM 元素就足够了，最后我停在了~45k，就像测试应用程序一样。甜甜圈图的结果很有趣……正如您所见，尽管 DOM 元素数量相同，但在键入相同数量的字符时执行的渲染更少。当然，FB 的事件处理程序据说比我的要复杂得多，如果按下 Enter 键，它只会附加另一个注释（这会导致 FB 的事件处理时间更长）。此外，在评论框中输入时（来自新闻提要中出现的第一个项目）FB 达到了37FPS，这也明显更好。
问题：如何改善按键的布局时间，有可能吗？难道是不同的HTML结构是原因吗？您可以看到 FB 在某些地方包含更多的嵌套元素，测试应用程序的嵌套更少，但显示了更多单独的帖子项。另外，如果我需要添加更多详细信息，请发表评论！:)