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

【问题标题】：Content-Visibility auto vs Lazy loading content performance内容可见性自动与延迟加载内容性能
【发布时间】：2020-09-22 14:38:14
【问题描述】：

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

【问题讨论】：

【解决方案1】：

关于这个有一个good article on web.dev。

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

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

因此我们可以推断，如果页面在 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 产生负面影响）！

【讨论】：