使用溢出时减少滚动卡顿：滚动；

Question

我有一个 2 列布局，右侧列是一个可滚动的结果列表，最多包含 200 个项目结果（基本上只是一个带有 overflow-y: scroll; 集的 ul）

我发现，当您滚动时，右侧的列会导致一些卡顿（这在低端硬件上尤其明显）。

在 chrome 时间轴中，当我滚动列时，我可以看到一些主要的“更新层树”。 有什么办法可以弄清楚为什么“更新图层树”如此冗长以及哪些 CSS 属性对速度的影响最大？ 当我点击它时 - 只告诉我它运行了多长时间而不是其他信息。

我在每个 li 中都有一些表现不佳的 CSS（例如过滤器、变换、框阴影等）- 如果我一个一个地删除每个 SASS 文件，它会提高滚动性能（并最终在我删除所有 CSS 后消除卡顿），但显然很难确定哪些 css 属性没有执行此操作。

我想知道我是否遗漏了 chrome 时间线中对这方面有帮助的内容？

我尝试使用 will-change CSS 属性将滚动提升到不同的层/强制硬件加速 - 但这并没有太大的区别。

我滚动时也没有执行任何 javascript 事件。

限制为少于 200 个项目不是一种选择。

我已经设置了一个示例（我知道它的项目列表较长，但这仅用于演示目的）： https://github.com/jooj123/jank/blob/master/scroll.html

真正有趣的是，如果我删除 overflow-y: scroll;（在上例中的 .map-search__results 中），滚动变得非常平滑并且卡顿消失 - 为什么会有这么大的效果？

这是 chrome 时间线（基本上只有很长的“更新层树”部分）：

修复：

Paul's answer about will-change: transform is spot on，特别是这条花絮帮助了：

“添加 will-change: transform;。一旦添加，“滚动重绘”矩形就消失了。”

但要小心，因为它并不总是适用于您的代码库，检查滚动性能问题指示器以确保“滚动重绘”已关闭，对我来说，我还必须禁用 -webkit-clip-path 属性（在我的在其中一个子 div 中设置的实际代码库 - 不在提供的演示中，请参阅：

Answer 1

我试了your test page看了看。

首先，对于滚动性能问题，我喜欢在“渲染”窗格中打开一些复选框：

我们可以立即看到这个 div 被称为“repaints on scroll”。然后，您可以在实验性图层面板中验证：

（我在树中右键单击并选择“显示内部层”顺便说一句）

现在大的“更新层树”成本通常是由很多层或几层尺寸非常大的层引起的。在这种情况下，我们真的两者都没有。但是我们确实有一个滚动层，它没有得到复合滚动。

复合滚动 == 快速滚动 == 通常是默认值。但是在这种情况下，我们会退回到“主线程滚动”，这真的很慢而且很糟糕。从好的方面来说，crbug.com/381840 即将被修复，它应该会自动修复这个测试用例。耶！但我们现在可以解决它。

解决方法

您确实提到您尝试过will-change，但没有效果，但我自己尝试效果很好。它属于设置了overflow 的元素，在本例中是.map-search__results 选择器。添加will-change: transform;。一旦添加，“滚动重绘”矩形就消失了。然后用时间线测量，效果会好很多。

这是之前/之后的视图：

link to viewer

祝你好运！

Answer 2

如果在滚动时您的问题明显可见，您应该能够在开发者工具中同时打开 timeline 和 styles 选项卡，取消选中适用的样式在样式选项卡中一一添加到您的元素，看看它如何影响滚动。这样您就可以独立测试每个样式规则，而不是测试整个 CSS 文件。如果您在 CSS 中使用 sourcemaps，您应该能够轻松地在实际的 CSS 文件中找到违规规则并进行调整。

如果您不熟悉使用样式选项卡：打开 Chrome 开发人员工具后，使用检查器工具（开发人员窗格的左上角）选择您怀疑可能会给您带来问题的项目。为选定元素关联或覆盖的所有样式都将在样式选项卡中列出。然后，您可以将它们一一关闭。您也可以使用检查器在嵌套项中钻取任意深度。

更新：

我在您编辑后拉下代码并仔细查看了它。我注意到您的溢出出现在您的 ul 项目上。就我个人而言，我从来没有在ul 上使用溢出（通常更喜欢div 之类的容器），所以出于好奇，我从你的ul 中删除了overflow-y:scroll，并将其放在ul 的包含div .right-content （并将其高度设置为 100%），然后滚动滚动消失了。

至于为什么，我只能推测，但我相信这与您滚动的项目数量有关。当您的溢出出现在 UL 上时，您将直接滚动所有这些子 li 项目。当它在包含div 时，实际上您只滚动ul，所以我相信这个过程在计算移动项目的位置时确定的数学要少得多。 1 div 定位调整 vs. 数百 li 调整。

如果您比较上图中的时间线，您会发现差异。最上面的是ul 上带有overlflow-y:scroll 的原始版本。您可以将鼠标悬停在更新树过程中的所有这些小线条上，并看到有数百个正在绘制的项目。这些是您的 li 项目。在第二个时间线中是我从ul 中删除溢出并将其应用于包含div 的版本。您可以在此时间线中看到更新树过程只有一项要绘制，即ul。如果您查看商品的尺寸，您也会看到尺寸上的差异。