內容可見性自動與延遲加載內容性能

Question

有沒有人測試過使用 Chrome 85 中的新 css 功能content-visibility: auto與其他延遲加載方法之間的性能差異的基准？ 是否值得將當前使用 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`

這不是延遲加載的替代品。 如果您必須在兩者之間進行選擇，請每次都選擇延遲加載！

延遲加載甚至不請求數據，直到需要它（如果正確完成）。 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 產生負面影響）！