2020 年測量頁面速度的高級概念

已發表: 2020-04-09

要了解 2020 年影響頁面速度的因素，我們首先需要了解瀏覽器如何呈現網頁。 如果您不熟悉頁面速度和 Web 技術概念，例如 DOM、CSSOM、渲染樹、回流成本和 DOM 類型，您可能想從閱讀上面鏈接的文章開始。

隨著網站和網絡瀏覽器變得越來越複雜，頁面速度變得不僅僅是頁面有多大或服務器響應速度有多快。 在本文中，我們將研究 2020 年及以後的一些新出現的頁面速度指標：資源請求的數量和大小、關鍵渲染路徑、LCP、CLS 和總阻塞時間。

本文是關於頁面速度的四篇系列文章中的第二篇。 您可以在此處找到第一篇文章：瀏覽器如何創建網頁？

管理資源請求的順序、大小和數量

渲染過程的每一步都需要時間。 查找網站速度慢的地方以及如何加快速度的方法涉及查看瀏覽器在渲染頁面的過程中如何處理資源。

這意味著請求的順序、數量和大小在當今衡量頁面速度方面發揮著重要作用。

資源順序和資源加載提示優化的最重要貢獻是通過最大內容繪製減少了 TTI（交互時間）。 通過資源順序優化，您可以在更短的時間內上傳相同數量、相同大小的文件，並交付給用戶和搜索引擎。

什麼是關鍵渲染路徑？

關鍵渲染路徑包括將創建首屏網頁部分的所有資源。

由於頁面的總加載大小，您的網頁可能比競爭對手的網頁慢。 但訣竅是：即使其他業務部門不允許您修復頁面的加載大小，您仍然可以通過優化關鍵渲染路徑來比競爭對手更快地提供內容。

如何優化關鍵渲染路徑

這是由 Sergey Chernyshev 創建的頁面速度和轉換率相關性模擬器。 如果我的網頁為用戶加載快 0.5 秒並將其顯示給您的開發團隊以指定每毫秒可以提高轉換率，您可能會找到問題的答案。

要優化關鍵渲染路徑，您需要確定創建折疊部分所需的資源。 之後，有幾個小問題要問：

  1. 哪些資源會阻止瀏覽器下載關鍵資源？
  2. 能否減少關鍵源的大小和數量？
  3. 可以內聯關鍵源嗎？
  4. 能否統一關鍵渲染路徑源來限制 DNS 查找過程？

我們來看一個例子。 我們還將提供一些加速 CSS、JS 和 HTML 的建議。

這是來自亞馬遜網頁的關鍵部分示例。 使用 DevTools，您可以在頁面的關鍵部分看到最​​重要的 <div> 元素以及必要的 CSS 代碼。 這樣，您可以在渲染阻塞資源干擾瀏覽器之前創建內聯 CSS 代碼塊。 您可能還會在底部看到未使用的代碼堆棧。 亞馬遜總是對不同的類別使用相同的 CSS/JS 資源模式，即使它們沒有經過優化。

除了速度之外，這裡還有另一個問題。 隨著手機屏幕尺寸的不同，網頁的關鍵部分因型號而異。 有些屏幕不顯示價格，有些屏幕不顯示股票信息。 這是一個重要的設計錯誤，但它也使關鍵的渲染路徑優化變得更加困難。 如果該區域有鏈接，它還會劃分PageRank值，並降低轉換的概率。

您可以使用 Puppeteer（Googlebot 的抓取引擎）來檢查此類問題，並為每個智能手機/平板電腦型號自動截屏，並檢查網頁關鍵部分的設計。 Jean-Francois Lagarde 為這項任務提供了一個不錯的 Puppeteer 庫，您可能想查看它。

這是每個設備視口工具的 Puppeteer 自動屏幕截圖中設備配置的快速屏幕截圖。

什麼是最大的內容塗料？

最大內容繪製 (LCP) 是網頁中字節和大小方面最大的區域。 在每個網頁中，都有很多“div”元素，它們都包含不同的頁面組件。 並且這些組件具有不同的頁面加載值。

根據 Google 的說法，最大內容繪製主要受頁面中最重要元素的影響。 為了讓您了解 LCP 的重要性，Google 決定在未來將這一新指標添加到 Lighthouse 報告中。

這也意味著我們將越來越多地聽到有關 LCP 的信息，因為它將與真實用戶指標 (RUM) 一起使用，並且將成為一個關鍵指標，尤其是在涉及關鍵渲染路徑的情況下。

這是 Lendio 提供的最大內容繪製示例。 如您所見，DevTools 在頁面上顯示 LCP 以及有關其類型、大小和加載時間的數據。 Largest Contentful Paint 的內容應該始終包括頁面的目的和價值，以及最重要的功能或 CTA——而且，最重要的是，它還應該首先加載！

在此示例中，它只是文本。 將它與功能工具結合起來會比僅使用文本/圖像 LCP 更好。

LCP 只考慮某些類型的資源。 這樣做的主要原因是首先保持 LCP 測量簡單。 下面是一個“腳本實例”，用於創建 LCP 條目列表。 研究這些代碼將告訴您 Google 開發人員在加載頁面時要注意什麼以及如何注意。

[暴露=窗口]
接口 LargestContentfulPaint : PerformanceEntry {
只讀屬性 DOMHighResTimeStamp 渲染時間；
只讀屬性 DOMHighResTimeStamp 加載時間；
只讀屬性 unsigned long 大小；
只讀屬性 DOMString id;
只讀屬性 DOMString url；
只讀屬性元素？ 元素;
[默認] 對象 toJSON();
};

您在此列表中看到的是比較進入 LCP 條目列表的候選項目所需的量表。 下面，我將向您展示選擇 LCP 候選者的方法（“大正文”和“大圖像”）。

了解定義 LCP 的原則和流程

確定 LCP 的原則極為重要：

  • 當頁面加載時，LCP 可以在幾秒鐘內改變。 有時，即使頁面組件作為 LCP 在屏幕上保持足夠長的時間，即使後面加載的較大頁面元素也不會改變之前的狀態。
  • 有時，首屏元素（在網頁的關鍵部分中）被選為 LCP，而不是首屏以下較大的項目（網頁的非關鍵部分）。
  • 如果其組件在屏幕上被拆分，則無法將較大的 <div> 元素選擇為 LCP。 相反，塊 <div> 元素將被選為 LCP。 下面您將看到一個示例來說明這一點。

在此示例中，我們看到最大的組件是 <div>，其中包含四個不同的圖像。 但是，這些單獨的圖像都沒有大於 Oncrawl 徽標和包含在同一 <div> 元素中的文本。 由於兩者都在網頁的關鍵部分，第二個元素將是 LCP。

在計算 LCP 時序和確定 Google Developers 的觀點時，您還應該關注“複合”設計。 如果一個 <div> 元素沒有復合和統一的設計感覺/視圖，它可能不會被選為 LCP。

即使它被選中，谷歌瀏覽器也可能認為這不是一個健康的 LCP，它會在未來添加到 LCP API 中的新代碼。 出於與 UX 相關的原因以及更好地了解頁面速度，Google 將繼續使用這些方法改善自己的感知。

什麼是版面移位和累積版面移位？

佈局轉移是指，當瀏覽器下載頁面時，頁面元素會以一種可能會干擾用戶的方式改變它們的位置。

在下載頁面時，每個頁面部分都將按照給定的順序一個接一個地可見。 這很正常。 但是如果這些部分因為後續部分而改變了它們的起始位置，這就是佈局轉移。

累積佈局移位 (CLS) 是所有佈局移位事件的總和。

Chrome 用戶體驗也有一個關於 CLS 分數的部分。 但這不僅僅是關於用戶體驗。 佈局移位可能對光敏性癲癇患者有害。 作為一家“健康公司”，谷歌也必須重視用戶的健康； 他們試圖盡可能減少“網絡壓力”。

“我相信谷歌已經是一家健康公司。 它從一開始就存在於公司的 DNA 中”
David Feinberg——谷歌健康負責人

這是一個簡單而決定性的佈局轉換示例，來自我們在本系列前面看到的同一站點之一。 這是來自土耳其的主要新聞網站，這是他們的主頁……

您可以從 Moz 開發人員那裡閱讀更多關於對健康有害的佈局偏移、閃爍、閃爍和顏色變化的信息。

如何在您的網站上找到累積的佈局變化

要查看網頁的佈局部分變化，您可以使用 Google Chrome DevTools 或者您可以使用 Layout Instability API 來擴展所有網頁的流程。

累積佈局移位，或所有佈局移位事件的總和，是 2020 年及以後頁面速度和用戶體驗的重要標準。 如果網頁的首屏部分在加載時發生移動，則在優化速度時還需要對其進行優化。

下面，您將找到 Layout Shifting Formula，以及 Layout Instability API 代碼示例，讓您了解 CLS 的貢獻以及計算 Layout Shifting Score 的方法。

版面移位公式如下：
佈局偏移分數 = 影響分數 * 距離分數

Layout Shifting 分數是使用兩個有用的新術語計算的，即影響分數和距離分數：

  • 影響分數是受移位影響的屏幕百分比。 您知道，如果頁面元素（覆蓋移動設備上 50% 的視口）造成佈局偏移，則您的 CLS 會很高，因為移動它會影響至少 50% 以上的屏幕。
  • 距離分數是通過換檔元件在換檔期間在其換檔方向上遠離其原始點的距離來衡量的。 如果第一個位置和最後一個位置之間的距離過大，則距離分數也會過大。

這將使您更容易估計您的 CLS 分數並為您的 IT 和 UX 團隊提供建議。

上面，你可以看到一個 CLS API 代碼片段，下面是一個 GIF，它顯示瞭如何計算 Cumulative Layout Shifting。

在我們一直在查看的同一個土耳其新聞網站上，我們的 CLS 是 0.47。 考慮到它是在 0 和 1 之間計算的，這是一個非常糟糕的分數。
您可以使用 Webpagetest.org 的高級自定義度量系統計算您的 CLS。 在“發送信息部分”之前，您應該使用 CLS API 的代碼。 之後，您需要將 URL 從 root/results/ 更改為 root/custom_metrics.php?test={Same Result Number}。

什麼是總阻塞時間？

您可以快速下載網頁的折疊部分，而無需進行任何佈局轉換，但如果它沒有響應用戶的輸入，Google 算法會聲稱您還有另一個 UX 和頁面速度問題。 總阻塞時間是在這個階段損失的時間。

與累積佈局移位和最大內容繪製一樣，總阻塞時間是 2020 年及以後的新頁面速度和用戶體驗指標。

計入總阻塞時間 (TBT) 的是首次繪製 (FP) 和交互時間 (TTI) 之間的任何加載事件，該事件阻塞瀏覽器（或設備）的主線程超過 50 毫秒並阻止用戶執行任何過程。

如何計算和優化 TBT

您可以使用 Long Tasks API 計算您的總阻塞時間 (TBT)。

為了優化您的 TBT 分數，您還應該關注加載資源的順序和偏好，以及請求的數量和大小。

這是來自以前的同一個站點。 您可能會注意到，主線程完全忙碌了超過 5 秒，不停。 他們的 LCP 在將近 2.5 秒後仍在加載……這裡要注意的重要一點是，他們最長的任務請求超過了 350 毫秒。 這意味著它被認為阻塞了主線程超過 300 毫秒。

此外，所有阻塞時間都計入總阻塞時間的一部分。 這不僅包括首屏部分中的元素，而且適用於所有網頁組件。 它會為您的網站創建有害的瀏覽器歷史記錄。

如果您的 TBT 超過 300 毫秒，這可能會大大損害您的用戶保留率和轉化率。

您可能會看到上面主線程的 TBT 計算示例。 在此示例中，有四個請求。 谷歌瀏覽器一次可以從同一台服務器創建 6 個請求。 只有前 50 個 MS 會順利進行； 之後它將開始同時執行多個任務，只要 CPU/網絡功率允許。 請記住，人類每 16 毫秒可以看到一幀。 谷歌關心用戶的每一毫秒。

在此示例中，總阻塞時間為 1 秒和 100 MS。

頁面速度優化的下一步

到目前為止，在本系列中，我們已經研究了瀏覽器如何創建網頁，這使我們能夠在本文中看到與頁面在瀏覽器中的加載方式相關的新指標如何影響頁面速度。 我們已經研究了一些最重要的新指標，以及如何衡量和優化它們。

在本系列的下一篇關於當今網站的頁面速度的文章中，我們將介紹一個已成為 SEO 和 Web 開發的主要主題的主題：優化 JavaScript 資產以提高頁面速度和頁面渲染。

開始免費試用