勝過 Google 的 PageSpeed Insights 評估

已發表: 2022-07-22

如果您是企業主,您有興趣為您的網站獲得更好的搜索排名。 如果您是開發人員,則需要滿足客戶的需求並創建一個能夠獲得良好排名的網站。 谷歌在確定其搜索引擎排名頁面 (SERP) 中網站的順序時會考慮數百個特徵。

頁面速度在 2018 年年中被正式列為重要的排名屬性。 在本文中,我們將解釋企業主應注意的性能分數:PageSpeed Insights。 我們將深入探討一些技術細節,這些細節將幫助軟件開發人員在復雜情況下進行改進,例如與單頁應用程序相關的情況。

為什麼 Acing Google 的 PageSpeed Insights 測試很重要

當谷歌在 2010 年推出 PageSpeed 工具時,大多數網站所有者都熟悉了它。 那些還沒有打開 PageSpeed Insights 的人應該檢查他們的網站。

該服務提供有關網站如何在桌面和移動瀏覽器上執行的詳細信息。 很容易錯過您可以使用分析頂部的移動和桌面選項卡在它們之間切換的事實:

谷歌 PageSpeed Insights 的屏幕截圖,顯示搜索框下方居中的兩個標籤。它們位於另外兩行文本之上,“發現您的真實用戶正在經歷什麼”和“根據來自世界各地的實際用戶的數據了解您的網站的表現如何”。

由於移動設備結構緊湊且旨在延長電池壽命,因此其網絡瀏覽器的性能往往低於運行桌面操作系統的設備,因此預計桌面分數會更高。

大型科技公司在任何領域都不會虧本,但預算緊張的小型網站可能會。 企業主還可以在競爭對手的網站上運行 PageSpeed Insights,並將結果與他們自己的結果進行比較,看看他們是否需要投資以提高性能。

什麼分數足以通過 PageSpeed 評估?

PageSpeed 使用來自 Core Web Vitals 的指標來提供通過/失敗評估。

這個工具有三個分數:

  1. PageSpeed 在診斷性能問題部分以彩色圓圈突出顯示性能分數。 它是使用 PageSpeed 的內置虛擬機計算得出的,這些虛擬機具有與普通移動或桌面設備相匹配的特性。 請記住,此值用於頁面加載和 PageSpeed 的虛擬機,Google 搜索引擎考慮該值。

    診斷性能問題部分的屏幕截圖,在綠色圓圈中顯示 100 分。

    當開發人員對網站進行更改時,此圖很有用,因為它允許他們檢查更改對性能的影響。 然而,谷歌的搜索引擎只考慮詳細的分數。

  2. 特定頁面(以及 PageSpeed 認為與所分析頁面相似的頁面)的詳細分數是根據 Chrome 瀏覽器在真實計算機上收集並發送給 Google 的統計數據計算得出的。 這意味著不考慮 Firefox、Safari 和其他非 Chromium 瀏覽器的性能。

    顯示此 URL 選項卡下特定頁面的詳細分數的屏幕截圖。屏幕截圖顯示了失敗的 Core Web Vitals 評估以及首次內容繪製 (FCP)、首次輸入延遲 (FID)、最大內容繪製 (LCP) 和累積佈局偏移 (CLS) 的分數。 CLS 得分為紅色,而 FCP、FID 和 LCP 為綠色。

  3. 網站所有頁面的摘要的獲取方式與單頁得分相同。 要訪問它,請選擇“源”選項卡而不是“此 URL”選項卡。 標籤欄下列出的 URL 將有所不同,因為 Origin 將顯示站點的主頁(僅限域)。

    顯示網站所有頁面詳細分數的屏幕截圖,位於“來源”選項卡下。屏幕截圖顯示了失敗的 Core Web Vitals 評估以及首次內容繪製 (FCP)、首次輸入延遲 (FID)、最大內容繪製 (LCP) 和累積佈局偏移 (CLS) 的分數。 FCP 分數為黃色,FID 和 LCP 分數為綠色,而 CLS 分數為紅色。

Google 會不斷更新 PageSpeed 考慮的指標列表,因此重要的最佳來源是 Google Search Console 中的 Experience / Core Web Vitals 部分,假設您已經在那裡添加了您的網站。

要通過 Core Web Vitals 評估,所有分數必須為綠色:

屏幕截圖顯示了通過的核心 Web Vitals 評估以及首次內容繪製 (FCP)、首次輸入延遲 (FID)、最大內容繪製 (LCP) 和累積佈局偏移 (CLS) 的分數。所有四個分數都有綠色值。

要使值變為綠色,頁面需要在測試中得分至少為 75%,並且許多用戶需要體驗相同或更好的值。 每個分數的閾值都不同,FID 的閾值要高得多。

要更好地理解這些值,請單擊分數標題:

First Contentful Paint (FCP) 分數的屏幕截圖,標題以紅色框突出顯示。

這鏈接到博客文章,更詳細地解釋了給定類別的閾值。

數據累積了 28 天,與真實用戶可能遇到的其他兩個主要差異:

  1. 真實設備的性能和網速各不相同,因此該測試產生的結果與 PageSpeed 的虛擬機結果不同。
  2. 詳細評級是在整個頁面生命週期內計算的,從頁面打開的每 5 秒間隔中獲取最差的值。

如果網站的許多用戶生活在互聯網訪問速度較慢的地區,並使用過時或性能不佳的設備,那麼差異可能會令人驚訝。 這不是 PageSpeed Insights 的改進建議之一。 乍一看,如何處理這個問題並不明顯,但我們稍後會嘗試解釋。

使用 PageSpeed Insights 建議提高分數

評分的主要部分來自大多數用戶打開頁面的方式。 儘管並非所有用戶都會長時間訪問一個網站,而且大多數用戶偶爾會訪問一個網站,但所有用戶都被考慮在評級中,因此提高影響每個人的頁面加載速度是一個不錯的起點。

我們可以在評估結果下方的“機會”部分找到建議。

機會部分的屏幕截圖顯示了多個改進機會,右側顯示了估計的頁面加載節省(以秒為單位)。在我們的示例中,我們有六項建議,從“避免多個頁面重定向”開始,預計可節省 1.56 秒,到“避免向現代瀏覽器提供舊版 JavaScript”,預計可節省 0.3 秒。

我們可以擴展每個項目並獲得詳細的改進建議。 有很多信息,但這裡是最基本和最重要的提示:

  • 提高服務器響應速度。 例如,如果您使用共享主機,請升級您的計劃或遷移到虛擬專用服務器 (VPS) 甚至專用服務器。 此外,並非所有主機都是平​​等的。 嘗試選擇具有良好硬件和正常運行時間保證的可靠主機。
  • 降低打開網站所需的流量。 為此,您可以用優化的圖像替換圖像:更改它們的格式、調整分辨率和壓縮、在需要時用靜態圖像替換動畫圖像等。流行的內容管理系統具有使此過程變得簡單的插件。
  • 緩存更多數據。 最簡單的方法是使用像 Cloudflare 這樣的內容交付網絡 (CDN) 來處理靜態內容(圖像、樣式、腳本、不會更改的頁面)。 您可以配置緩存規則以優化性能。

現在讓我們看看更複雜的因素,有經驗的程序員可以提供幫助。

如何在頁面生命週期中調試分數

如前所述,Google Search Console 會考慮過去 28 天從基於 Chromium 的瀏覽器獲得的平均分數,還包括頁面整個生命週期的值。

無法查看頁面生命週期中發生的情況是一個問題。 PageSpeed 的虛擬機無法解釋頁面加載後的執行情況以及用戶與之交互的情況,這意味著網站開發人員將無法獲得改進建議。

解決方案是在站點項目的開發人員版本中包含 Google Chrome Web Vitals 庫,以查看用戶與頁面交互時發生的情況。

GitHub 上的 README.md 文件中提供了有關如何包含此庫的各種選項。 最簡單的方法是添加以下腳本。 它被調整為在主模板的<head>中顯示頁面生命週期內的值:

 <script> (function() { var script = document.createElement('script'); script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.iife.js'; script.onload = function() { // When loading `web-vitals` using a classic script, all the public // methods can be found on the `webVitals` global namespace. webVitals.getCLS(console.log, true); // CLS supported only in Chromium. webVitals.getLCP(console.log, true); // LCP supported only in Chromium. webVitals.getFID(console.log, true); webVitals.getFCP(console.log, true); webVitals.getTTFB(console.log, true); } document.head.appendChild(script); }()) </script>

請注意,累積佈局偏移 (CLS) 和最大內容繪製 (LCP) 計算僅適用於基於 Chromium 的瀏覽器,包括 Chrome、Opera、Brave(禁用 Brave Shields 以使庫工作)和大多數其他現代瀏覽器,Firefox 除外,它基於 Mozilla 引擎和 Apple 的 Safari 瀏覽器。

添加腳本並重新加載頁面後,打開瀏覽器的開發者工具並切換到控制台選項卡。

Google Chrome 瀏覽器中控制台選項卡的屏幕截圖,顯示 FCP、TTFB、FID 和 LCP 值,每個值都作為控制台輸出的一行,其中包含具有屬性“名稱”、“值”、“增量”、“條目”的對象, ”和“身份證”。 “條目”的值是一個數組。
Chrome 控制台選項卡中的 Chrome Web Vitals 庫提供的值

要查看如何為移動版本計算這些值,請使用“設備”工具欄切換到移動設備。 要訪問它,請單擊瀏覽器開發者工具中的切換設備工具欄按鈕。

Google Chrome 開發者工具頂部“檢查元素”按鈕和“元素”選項卡之間的“切換設備工具欄”按鈕的屏幕截圖。

這將有助於查明問題。 展開控制台中的行將顯示觸發分數變化的詳細信息。

大多數情況下,其他分數的自動建議足以了解如何改進它們。 但是,在頁面加載了用戶交互之後,CLS 會發生變化,並且可能根本沒有任何建議,尤其是對於單頁應用程序。 即使您的頁面未能通過搜索引擎考慮的因素的評估,您也可能會在“診斷性能問題”部分看到完美的 100 分。

對於我們這些在 CLS 中苦苦掙扎的人來說,這將很有幫助。 展開日誌記錄,然後是條目、特定條目、來源、特定來源,並將currentRectpreviousRect進行比較:

日誌記錄的圖像,突出顯示 currentRect 和 previousRect 值。

現在我們可以看到發生了什麼變化,我們可以確定一些修復它的方法。

減少累積佈局偏移

在所有分數中,CLS 是最難掌握的,但它對用戶體驗至關重要。 將元素添加到文檔對像模型 (DOM) 或更改現有元素的大小或位置時會發生佈局偏移。 它會導致該元素下方的元素發生移動,並且用戶感覺他們無法控制正在發生的事情,從而導致他們離開網站。

在一個簡單的 HTML 頁面上處理這個相對容易。 設置圖像的寬度和高度屬性,以便它們下方的文本在加載時不會移動。 這可能會解決問題。

如果您的頁面是動態的並且用戶使用它就像使用應用程序一樣,請考慮以下步驟來解決 CLS 問題:

  1. 將頁面設置為在用戶單擊按鈕或鏈接後 500 毫秒顯示內容,而不會觸發 CLS。
  2. 更改不會導致其他 DOM 元素移動的參數:背景、顏色等。
  3. 確保在更改元素的大小或位置時其他元素不會移動。

Google Developers 優化 CLS 頁面提供了更詳細的建議。

500 毫秒如何減少 CLS

為了說明如何使用 500 毫秒閾值,我們將使用一個涉及圖像上傳的示例。

通常,當用戶上傳文件時,腳本會在 DOM 中添加一個<img>元素,然後客戶端瀏覽器會從服務器下載圖像。 從服務器獲取圖像可能需要超過 500 毫秒,並且可能會導致佈局偏移。

但是有一種方法可以更快地獲取圖像,因為它已經在客戶端計算機上,因此可以在 500 毫秒截止日期之前創建<img>元素。

這是一個關於純 ECMAScript 的通用示例,沒有適用於大多數現代瀏覽器的庫:

 <!DOCTYPE html> <html> <head></head> <body> <input type="file"> <img> <script> document.getElementById('input').addEventListener('change', function() { var imageInput = document.getElementById('input'); if (imageInput.files && imageInput.files[0]) { var fileReader = new FileReader(); fileReader.onload = function (event) { var imageElement = document.getElementById('image'); imageElement.setAttribute('src', event.target.result); } fileReader.readAsDataURL(imageInput.files[0]); } }); </script> </body> </html>

正如我們之前看到的,解決這類問題可能需要思維敏捷。 對於移動設備,尤其是便宜的設備,以及緩慢的移動互聯網,90 年代的性能優化藝術變得有用,而老式的網絡編程方法可以激發我們的技術。 現代瀏覽器調試工具將對此有所幫助。

更新 Google 搜索控制台

發現並消除問題後,Google 的搜索引擎可能需要一些時間來註冊更改。 要更快地更新結果,請讓 Google Search Console 知道您已解決問題。

使用左上角的搜索屬性框選擇您正在處理的頁面。 然後導航到左側漢堡菜單中的 Core Web Vitals:

通過 Google Search Console 左上角的 Search 屬性下拉框顯示 Core Web Vitals 選項的屏幕截圖。

單擊移動或桌面報告右上角的打開報告按鈕。 (如果您在這兩種情況下都遇到問題,請記住稍後對第二份報告重複相同的操作。)

Google Search Console Core Web Vitals 部分的屏幕截圖,顯示主標題下方時間戳下方“移動”欄右側的“打開報告”標籤。

接下來,轉到圖表下的詳細信息部分,然後單擊帶有失敗驗證警告的行。

Google Search Console Core Web Vitals 中詳細信息部分的屏幕截圖,顯示移動設備的結果不佳。分數為 17,CLS 問題(“超過 0.25(移動)”)導致驗證失敗。

然後單擊此問題的查看詳細信息按鈕。

顯示用戶單擊“驗證失敗”欄右側的查看詳細信息按鈕後發生的情況的屏幕截圖。該工具報告了 17 個受影響的 URL。

最後單擊開始新驗證。

Google Search Console 的屏幕截圖顯示“驗證失敗”欄右側的“開始新驗證”按鈕,位於“驗證詳細信息”欄下方,位於 Google Search Console 主標題下方。

不要指望立竿見影的效果。 驗證最多可能需要 28 天。

Google Search Console 屏幕截圖顯示驗證過程已開始並將在 28 天內完成。

優化是一場持續的鬥爭

SEO優化是一個持續的過程,性能優化也是如此。 隨著受眾的增長,服務器會收到更多請求,響應會變慢。 不斷增長的需求通常意味著向您的站點添加新功能,它們可能會影響性能。

當談到性能優化的成本/收益方面時,有必要取得適當的平衡。 開發人員不需要一直在所有站點上實現最佳價值。 專注於導致最重要的性能問題的原因; 您將更快、更省力地獲得結果。 大公司有能力投入大量資源並獲得所有分數,但中小型企業並非如此。 實際上,小型企業很可能只需要匹配或超越競爭對手的表現,而不是像亞馬遜這樣的行業巨頭。

企業主應該了解為什麼網站優化很重要,工作的哪些方面最重要,以及在他們僱用的人身上尋找哪些技能。 就開發人員而言,他們應該始終牢記性能,幫助他們的客戶創建不僅讓最終用戶感覺快速,而且在 PageSpeed Insights 中得分很高的網站。