[譯] Google 的 Pagespeed 的工做原理：提高你的頁面分數和搜索引擎排名

時間 2019-12-07

標籤 google pagespeed 原理提高頁面分數搜索引擎排名欄目 Google 简体版

原文原文鏈接

原文地址：Google 的 Pagespeed 的工做原理：提高你的分數和搜索引擎排名

原文做者：Ben Schwarz

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：Jerry-FD

校對者：weberpan，Endone

經過這篇文章，咱們將揭開 PageSpeed 最爲重要的頁面速度評分的計算方法。javascript

毫無疑問，頁面的加載速度已經成了提高頁面收益和下降流失率的關鍵性因素。因爲 Google 已經將頁面的加載速度列入影響其搜索排名的因素，如今更多的企業和組織都把目光聚焦在提高頁面性能上了。html

去年 Google 針對他們的搜索排名算法作了兩個重大的調整：前端

三月，搜索結果排名以移動端版本的頁面爲基礎，取代以前的桌面端版本。
七月，SEO 排名算法更新爲，增長頁面的加載速度做爲影響其搜索排名的因素，如移動端頁面排名和廣告排名。

經過這些改變，咱們能夠總結出兩個結論：java

手機端頁面的加載速度會影響你整站的 SEO 排名。
若是你的頁面加載很慢，就會下降你的廣告質量分，進而你的廣告費會更貴。

Google 道：react

更快的加載速度不只僅會提高咱們的體驗；最近的數據顯示，提高頁面的加載速度也會下降操做成本。和咱們同樣，咱們的用戶就很重視速度 — 這就是咱們決定將頁面的速度這一因素，加入搜索排名計算的緣由。android

爲了從頁面性能的角度搞清楚這些變化給咱們帶來了什麼影響，咱們須要掌握這些基礎知識。PageSpeed 5.0 是以前版本的一次顛覆性的改動。如今由 Lighthouse 和 CrUX 提供技術支持（Chrome 用戶體驗報告部）。webpack

此次升級使用了新的評分算法，將會使得到 PageSpeed 高分更加困難。ios

PageSpeed 5.0 有哪些變化?

5.0 以前，PageSpeed 會針對測試的頁面給出一系列指導意見。若是頁面裏有很大的、未經壓縮的圖片，PageSpeed 會建議對圖片壓縮。再好比，漏掉了 Cache-Headers，會建議加上。git

這些建議是與一些指導方針對應的，若是聽從這些指導方針，極可能會提高你的頁面性能，但這些也僅僅是表層的，它不會分析用戶在真實場景下的加載和渲染頁面的體驗。github

在 PageSpeed 5.0 中，頁面在 Lighthouse 的控制下被載入到真實的 Chrome 瀏覽器中。Lighthouse 從瀏覽器中獲取記錄各項指標，把這些指標套入得分模型裏計算，最後展現一個總體的性能分。根據具體的分數指標來給出優化的指導方針。

和 PageSpeed 相似，Lighthouse 也有一個性能分。在 PageSpeed 5.0 中，性能分直接從 Lighthouse 裏獲取。因此如今 PageSpeed 的速度分和 Lighthouse 的性能分同樣了。

既然咱們知道了 PageSpeed 的分數從哪裏來，接下來咱們就來仔細研究它是如何計算的，以及咱們該如何有效的提升頁面的性能。

Google Lighthouse 是什麼?

Lighthouse 是一個開源項目，由一隻來自 Google Chrome 的優秀團隊運做。在過去的幾年裏，它已逐步變成免費的性能分析工具。

Lighthouse 使用 Chrome 的遠程調試協議來獲取網絡請求的信息、計算 JavaScript 的性能、評估無障礙化級別以及計算用戶關注的時間指標，好比首次內容繪製時間 First Contentful Paint、可交互時間 Time to Interactive 和速度指標。

若是你想要深刻了解 Lighthouse 的總體架構，請看來自官方的教程。

Lighthouse 如何計算性能分數

在性能測試中，Lighthouse 聚焦於用戶所見和用戶體驗，記錄了不少指標。

下面這 6 個指標構成了性能分數的大致部分。他們是：

可交互時間 Time to Interactive (TTI)
速度指標 Speed Index
首次內容繪製時間 First Contentful Paint (FCP)
首次 CPU 空閒時間 First CPU Idle
首次有效繪製 First Meaningful Paint (FMP)
預計輸入延遲時間 Estimated Input Latency

Lighthouse 會針對這些指標運用一個 0 – 100 的分數模型。這個過程會收集移動端第 75 和第 90 百分位的 HTTP 檔案，而後輸入到對數正太分佈函數（校對者注：這樣的話只要性能數據低於 25% 的線上移動端頁面，也就是排位在 75% 如下，都給 0 分，而只要比 95% 的移動端頁面得分高，就得滿分）。

根據算法和可交互時間的計算所得數據，咱們能夠發現，若是一個頁面在 2.1 秒內成爲「可交互的」，那麼它的可交互時間分數指標是 92/100。

當每一個指標完成計分後會被分配一個權重，用權重調整後算出頁面總體的性能分數。權重規則以下：

指標	權重
可交互時間 (TTI)	5
速度指標	4
首次內容繪製時間	3
首次 CPU 空閒時間	2
首次有效繪製	1
預計輸入延遲時間	0

這些權重取決於每一個指標對移動端用戶的體驗的影響程度。

在將來，這些權重在參考來自於 Chrome 用戶體驗報告的用戶觀測數據以後，還可能會被進一步優化。

你可能想知道究竟這每個指標的權重是如何影響總體得分的。Lighthouse 團隊打造了一款實用的 Google 電子表格計算器來闡述具體的細節：

使用上面的例子，若是咱們把可交互時間從 5 秒變爲 17 秒 (全球移動端平均 TTI)，咱們的分數會下降到 56% (也就是 100 分之中的 56 分)。

然而，若是咱們把首次內容繪製時間變爲 17 秒，咱們的分數會是 62%。

可交互時間 (TTI) 是對你的性能分數影響最大的指標。

所以，想要獲得 PageSpeed 的高分，你最須要的是下降 TTI。

劍指 TTI

深刻來講，有兩個對 TTI 影響極大的重要因素：

傳輸到頁面的 JavaScript 代碼的總大小
主線程上 JavaScript 的運行時間

咱們的可交互時間文章詳細說明了 TTI 的工做原理，但若是你想要一些快速無腦的優化，咱們建議：

下降 JavaScript 總大小

儘量地，移除無用的 JavaScript 代碼，或者只傳輸當前頁面會執行的代碼。這可能意味着要移除老的 polyfills 或者儘可能採用更小、更新的第三方庫。

你須要記住的是 JavaScript 花費的不只僅是下載它所須要的時間。瀏覽器須要解壓、解析、編譯而後才最終執行，這些過程都會消耗不容忽視的時間，尤爲在移動設備上。

能下降你的頁面腳本總大小的有效措施是：

檢查並移除對你的用戶來講並不須要的 polyfills。
搞清楚每個第三方 JavaScript 庫所花費的時間。使用 webpack-bundle-analyser 或者 source-map-explorer 來可視化分析他們的大小。
現代 JavaScript 工具（好比 webpack）能夠把大的 JavaScript 應用分解成許多小的 bundles，隨着用戶的瀏覽而動態加載。這就是所謂的 code splitting，它會極大地優化 TTI。
Service workers 會緩存解析和編譯後所得的字節碼。若是善加利用這個特性，用戶只需花費一次解析和編譯代碼帶來的時間損耗，在那以後的結果就會被緩存優化。