谷歌搜索引擎核心算法揭秘：如何完成秒級頁面互動？

作者丨Ben Schwarz

譯者丨核子可樂

眾所周知，速度已經成為各類網站增加收入並提升訪客駐留率的核心因素。如今，谷歌也開始將頁面速度納入排名因素考量，這直接促使更多組織將注意力集中在性能身上。本文，我們將探討 PageSpeed 如何計算最重要的這項指標：速度得分。

去年，谷歌公司對其搜索索引及排名算法做出了兩項重大變更：

去年 3 月，索引編目開始基於頁面的移動版本，而非桌面版。

去年 7 月，SEO 排名算法迎來更新，將頁面速度作為移動頁面及廣告的排名因素。

由此，我們可以總結出兩點可靠結論：

站點在移動設備上的速度將影響整體掃描引擎優化排名。

如果頁面加載速度較慢，則會降低廣告質量得分，意味著廣告成本將因此上升。

谷歌方面寫道：

速度更快的網站不僅能夠改善用戶體驗。最近的調查數據顯示，提高網站速度還有助於降低運營成本。像我們一樣，每位用戶都能夠通過速度獲得巨大的價值收益，因此我們決定將網站速度納入搜索排名的考量當中。

為了從性能角度理解這些調整會對我們造成怎樣的影響，首先需要理解其中的基礎性技術。PageSpeed 5.0 可謂對以往版本做出了徹底顛覆，其現在由Lighthouse 以及CrUX（Chrome 用戶體驗報告）提供支持。

此次升級還帶來了一種新的評分算法，使得網站更難獲得較高的 PageSpeed 得分。

1

PageSpeed 5.0 發生了哪些變化？

在 5.0 版本之前，PageSpeed 會針對特定頁面運行一系列啟發式算法。如果頁面中包含大量未經壓縮的圖像，則 PageSpeed 會建議進行圖像壓縮。如果缺少 Cache-Header，PageSpeed 也會建議立即添加。

這些啟發式方法還與系列指導方針相結合。當然，我們不能簡單地認為只要遵循這些指導方針，就足以帶來更理想的性能。因為其中並不涉及對真實訪客所面對的負載與渲染體驗進行實際分析。

在 PageSpeed 5.0 當中，頁面會被加載至由 Lighthouse 控制的真實 Chrome 瀏覽器當中。Lighthouse 會記錄來自瀏覽器的指標，利用評分模型進行指標分析，並給出整體性能得分。根據具體的指標評分方式，PageSpeed 即可給出改進建議。

與 PageSpeed 類似，Lighthouse 同樣提供性能評分。在 PageSpeed 5.0 當中，性能得分會直接被發送給 Lighthouse。這意味著 PageSpeed 的速度得分現在與 Lighthouse 性能得分保持一致。

現在，我們了解了 PageSpeed 的得分來源，下面開始深入了解具體得分的計算方法，以及如何對其進行有意義的改進。

2

谷歌 Lighthouse 是什麽？

Lighthouse 是一個由谷歌 Chrome 旗下專項團隊負責運營的開源項目。過去幾年以來，其已經逐步發展成一款免費的性能分析工具。

Lighthouse 採用 Chrome 的遠程調試協議讀取網絡請求信息、測量 JavaScript 性能、觀察可訪問性標準，並測量以用戶為中心的各項時序指標，包括首次內容填充、互動時間或者索引速度等。

Lighthouse 如何計算性能得分

在性能測試過程中，Lighthouse 會記錄下一系列與用戶觀感及體驗相關的指標。

總體性能得分的建立基於六項具體指標，分別為：

互動時間 (TTI)

索引速度

首次內容填充 (FCP)

首次 CPU 空閑

首次有意義填充 (FMP)

估算輸入延遲

Lighthouse 會為以上各項指標打出 0 到 100 之間的得分。整個過程會從 HTTP Archive 當中提取第 75 與第 95 百分位的移動測量指標，而後應用一項 log normal 函數。

根據用於計算互動時間的算法與參考數據，我們可以看到，如果頁面在 2.1 秒之內實現“互動”，則互動時間指標的標準得分為 92/100。

每項指標接受評分之後，Lighthouse 會為其分配一個權重，該權重作為總體性能得分計算中的調節器。具體權重如下所示：

這些權重代表著每一項指標對移動用戶體驗造成的具體影響。

未來，大家還可以引入來自 Chrome 用戶體驗報告數據集的用戶觀察數據來進一步增強估算結果。

您可能希望了解每項指標的權重如何影響整體性能得分。Lighthouse 團隊開發出一款實用的谷歌 Spreadsheet 計算機，用以解釋整個過程：

使用上述示例，如果我們將互動時間從 5 秒改為 17 秒（全局平均移動 TTI），那麽，我們的得分將降至 56%（即 100 分製中的 56 分）。

如果我們將首次內容填充指標修改為 17 秒，那麽得分將為 62%。

互動時間 (TTI) 是性能得分當中最重要的一項指標。

因此，要獲得較高的 PageSpeed 得分，需要優先關注 TTI 速度水準。

如何改善 TTI？

從高級視角來看，有兩個重要因素會對 TTI 產生直接影響：

傳遞給頁面的 JavaScript 代碼量

主線程上 JavaScript 任務的運行時間

我們在互動時間指南當中解釋了 TTI 的具體工作原理，如果大家希望快速了解情況，我們將優化思路總結如下：

減少 JavaScript 代碼量在可能的情況下，刪除未使用的 JavaScript 代碼或者確保僅交付當前頁面需要運行的腳本。這可能意味著您需要刪除舊的 polyfill，或者使用更小、更現代的第三方庫作為替代。需要注意的是，JavaScript 代碼帶來的成本並不僅僅體現在下載時間上。瀏覽器需要對相關代碼進行解壓縮、解析、編譯以及最終執行，這一切都會帶來可觀的處理時間，特別是在移動設備當中。

下面來看減少頁面中腳本數量的有效方法：

審查並刪除訪客並不需要的 polyfills。

了解各類第三方 JavaScript 的性能成本。使用 webpack-bundle-analyser 或者 source-map-explorer 對各個庫的大小進行可視化。

現代 JavaScript 工具（例如 Webpack）能夠將大型 JavaScript 應用拆分成一系列小型捆綁包，這些捆綁包會在用戶導航時自動加載。這種方法被稱為代碼拆分，且具有顯著的 TTI 改進效果。

服務工作程序會緩存經過解析且編譯的腳本的字節碼結果。如果能夠使用此項功能，那麽訪問者只需要付出一次性解析與編譯成本，接下來相關結果都可以從緩存中直接調用。

監控互動時間

為了成功發現用戶體驗中的重大差異，我們建議使用性能監控系統（例如 Calibre），其允許通過至少兩台設備進行測試，包括一台調整台式設備與一台中低端移動手機。

通過這種方式，開發者就能夠得到最佳與最差情況下的客戶體驗數據。下面，我們以客戶使用低性能硬體為例，聊聊如何進行體驗優化。

深入手動分析

為了在分析 JavaScript 性能方面獲得最佳結果，大家應該主動使用低性能設備進行頁面測試。如果您的辦公桌裡恰好有一部舊手機，是時候讓它再發揮一波余熱了。

另有一種理想的真實設備替代方案，即使用 Chrome DevTools 硬體仿真模式。我們編寫了一份廣泛的性能分析指南，可幫助大家快速理解運行時性能。

3

其它指標處理

接下來是索引速度、首次內容填充以及首次有意義填充，這些都是瀏覽器填充方面的指標。它們也受到類似因素的影響，而且一般能夠同時接受優化。

通過頁面呈現的速度計算這些指標，能夠在客觀上降低指標的改進難度。另外，您可以根據 Lighthouse 性能審查規則對這些指標做出優化。如果尚未預加載字體或者針對關鍵請求進行優化，那麽這兩項工作無疑應該首先完成。

4

跟蹤進度並進行有意義的改進

谷歌最近更新了搜索控制台，Lighthouse 與 PageSpeed Insights 都是快速獲得頁面性能直觀結果的好辦法。但對於需要持續跟蹤並改善網頁性能的用戶而言，其功能可能仍然不夠理想。持續性能監控對於確保最終速度改進至關重要，並且能夠在性能退化時立即向團隊發送通知。手動測試則可能在結果當中引入意想不到的變化，而且如果沒有專門的實驗室環境，我們幾乎不可能在不同區域及各類設備之上進行測試。

速度已經成為搜索引擎優化排名中的關鍵因素，特別是考慮到目前近 50% 的網絡流量都來自移動設備。為了避免排名下降，請確保使用最新性能套件跟蹤關鍵頁面（pssst，我們將 Calibre 打造成性能伴侶，其中內置有 Lighthouse。目前全球範圍內數百支團隊都在日常使用這款工具）。

https://calibreapp.com/blog/how-pagespeed-works/

點個在看少個 bug