内容可见性自动与延迟加载内容性能

Question

有没有人测试过使用content-visibility: autoChrome 85 中的新 css 功能与其他延迟加载方法之间的性能差异的基准？是否值得将当前使用 JavaScript 的延迟加载切换为使用 CSS content-visibility: auto？

Answer 1

关键的一点是，在他们的一个非常长的页面示例中，渲染速度提高了 7 倍，在低端移动设备上，这显然会被大大放大。

在我们的示例中，我们看到渲染时间从 232 毫秒提高到 30 毫秒。这是 7 倍的性能提升。

因此我们可以推断，如果页面在 Mac 上从 232 毫秒变为 30 毫秒，那么在中端手机上可能高达 1 秒与 120 毫秒，因为 CPU 慢了大约 4 倍。

旁注： 对于 CPU 速度差异，Lighthouse 存储库中的此页面底部有一个漂亮的表格，它解释了高端笔记本电脑与中低端手机的相对性能，只是为了让您知道我在哪里得到了 4 倍的减速.

延迟加载和延迟加载的区别 `content-visibility: auto`

这不是延迟加载的替代品。如果您必须在两者之间做出选择，请每次都选择延迟加载！

延迟加载甚至不请求数据，直到需要它（如果正确完成）。content-visibility: auto意味着浏览器仍将请求所有数据，只是不会呈现它。

这篇文章中的代码笔可以让您确认这一点。如果您打开网络选项卡并重新加载页面，您将看到所有资源都已下载，但如果您保留以下 CSS，渲染时间会大大缩短（如果您将其删除，您会看到渲染时间增加）

.story {
  content-visibility: auto;
  contain-intrinsic-size: 100px 1000px;
}

由于站点上的大多数速度问题都归结为网络请求，因此仍然需要通过网络发送的数据延迟加载，并且远远优于仅添加content-visibility: auto到每个部分。

我的意思是，是的，我愿意。

假设您的页面结构正确，您应该不会有任何问题。设置事物的内在高度和宽度是我需要进一步调查的事情，以查看如果您弄错了这是否对累积布局移位有任何影响。

旁注：据我所知，如果您弄错了容器的尺寸，它会正常工作，contain: paint因此您不会获得完全相同的好处。这纯属猜想，请勿将其作为答案的一部分！

如果您的用户群主要在移动设备上使用 Chrome（根据 caniuse.com 占所有浏览器的 35%），我会特别考虑实施它，因为 Chrome支持它。

最坏的情况是它永远不会在其他浏览器中实现（尽管 Firefox 已经在考虑实现它，而 Edge 显然已经支持 Chromium）。

在这个阶段，你有一个可能会被弃用的 CSS 属性，为了一两个千字节，它不会受到伤害（假设它不会像我之前所说的那样对 CLS 产生负面影响）！