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

Question

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

Answer 1

有一个good article on web.dev对这个。
关键的收获是，在他们的一个非常长的页面示例中，渲染速度提高了 7 倍，在低端移动设备上，这显然会被大大放大。

In our example, we see a boost from a 232ms rendering time to a 30ms rendering time. That's a 7x performance boost.

因此我们可以推断，如果页面在 Mac 上从 232 毫秒变为 30 毫秒，那么在中端手机上可能高达 1 秒与 120 毫秒，因为 CPU 慢了大约 4 倍。
旁注: For CPU speed differences this page from the Lighthouse repository底部有一张漂亮的表格，解释了高端笔记本电脑与中低端手机的相对性能，让你知道我在哪里减速了 4 倍。
延迟加载和 content-visibility: auto 的区别
这不是延迟加载的替代品。 如果您每次都必须在两者之间进行选择，请选择延迟加载!
延迟加载甚至在需要时才请求数据(如果正确完成)。 content-visibility: auto意味着浏览器仍然会请求所有数据，只是不会渲染它。
This codepen from the article让你确认。如果您打开网络选项卡并重新加载页面，您将看到所有资源都已下载，但是如果您保留以下 CSS，渲染时间会大大降低(如果您删除它，您会看到渲染时间增加)

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

由于站点上的大多数速度问题都归结为网络请求和通过网络发送的数据，因此仍然需要延迟加载，并且远远优于仅添加 content-visibility: auto。到每个部分。
我应该使用它吗？
我的意思是，是的，我愿意。
假设您的页面结构正确，您应该没有任何问题。设置事物的固有高度和宽度是我需要进行更多调查以查看这是否对 Cumulative Layout Shift 有任何影响。如果你弄错了。
旁注:据我了解，如果您弄错容器的尺寸，它将像 contain: paint 一样工作所以你不会得到完全相同的好处。这纯属猜想，请勿将此作为答案的一部分!
如果您的用户群主要在移动设备上使用 Chrome (35ish percent of all browsers according to caniuse.com)，我会特别考虑实现它，因为它在 Chrome 上受支持。
最坏的情况是它永远不会在其他浏览器中实现(尽管 Firefox 已经在考虑实现它，而 Edge 显然已经支持 Chromium)。
在这个阶段，你有一个可能会被弃用的 CSS 属性，为了一两个千字节，它不会受到伤害(假设它不会像我之前所说的那样对 CLS 产生负面影响)!