PageSpeed Insights 的行動版分析

PageSpeed Insights 會分析網頁，確認網頁是否符合我們的建議，讓你透過行動網路在一秒內轉譯網頁。研究顯示，只要延遲超過 1 秒就會讓使用者感到使用不暢，導致使用體驗不佳。我們的目標是讓使用者無論使用哪種裝置或網路，都能持續與網頁互動，並提供最佳體驗。

要用完 1 秒的預算並不容易，幸好，我們並不需要在預算範圍內轉譯整個網頁，只要在一秒內傳送並轉譯不需捲動位置 (ATF) 的內容，讓使用者能盡快開始與網頁互動即可。 接著，當使用者解讀第一頁的內容時，可在背景中逐步傳送網頁的其餘部分。

適應高延遲的行動網路

滿足 1 秒鐘的 ATF 標準，對行動裝置造成獨特的挑戰，這是其他聯播網所沒有的。使用者可能會透過 2G、3G 和 4G 等各種網路存取您的網站，網路延遲時間大幅高於有線連線，並且將大部分 1000 毫秒預算用在轉譯 ATF 內容。

4G 是全球最主要的網路類型，預期大部分使用者會透過 4G 網路存取您的網頁。因此，我們必須假設每個網路要求平均會花費 100 毫秒。

有鑑於此，我們現在要往回推算。如果我們在查詢瀏覽器和伺服器之間的一般通訊序列中，發現網路流量已用了 300 毫秒：DNS 查詢將主機名稱 (例如 google.com) 解析為 IP 位址、執行 TCP 握手的網路往返作業，以及選用的 TLS 連線。剩下 700 毫秒。

提供 1 秒內搞定的轉譯體驗

減去網路延遲時間後，我們只剩下 700 毫秒的預算，而且要處理許多工作：伺服器必須轉譯回應，用戶端應用程式程式碼必須執行，而瀏覽器必須配置及轉譯內容。瞭解這些之後，我們可以參考以下標準將費用控制在預算範圍內：

(1) 伺服器必須在 200 毫秒內轉譯回應
伺服器回應時間是指在除去網路傳輸時間的情況下，伺服器傳回初始 HTML 所需的時間。因為我們剩下的時間實在太少，所以必須將這個時間控制在最低限度，理想情況是少於 200 毫秒，而且越少越好！
(2) 儘量減少重新導向的次數
額外的 HTTP 重新導向可能會額外產生一或兩次的網路來回行程 (如果需要額外的 DNS 查詢，則會產生二次)，但在 4G 網路中，這會產生數百毫秒的額外網路延遲時間。因此，我們強烈建議網站管理員減少重新導向的次數，最好是完全移除重新導向；這在處理 HTML 檔案時尤為重要 (儘量避免重新導向到「m.」)。
(3) 儘量減少首次轉譯所需的來回行程次數

基於 TCP 預估連線能力的方式 (即 TCP 慢速啟動)，新的 TCP 連線無法立即使用用戶端和伺服器之間的完整可用頻寬。因此，伺服器在第一次往返時可透過新連線 (約 14 KB) 傳送最多 10 個 TCP 封包，接著必須等待用戶端確認這些資料，才能增加壅塞時間，並繼續傳送更多資料。

另請注意，TCP 標準的最近更新了 10 個封包 (IW10) 限制，因此請務必確保您的伺服器已升級至最新版本，以便享有這項異動。否則，這個上限可能降為 3 至 4 個封包！

基於這個 TCP 行為，請務必將內容最佳化，盡可能減少傳送必要資料以執行第一次轉譯頁面時所需的往返次數。在理想情況下，ATF 內容的大小應小於 98 KB，這樣一來，瀏覽器只需三次往返就能繪製頁面，並有足夠的時間處理伺服器回應延遲和用戶端轉譯。

(4) 避免不需捲動位置的內容中出現外部封鎖 JavaScript 和 CSS

瀏覽器必須先剖析網頁，才能將網頁轉譯給使用者。如果剖析時遇到不屬於非同步的指令碼或封鎖外部指令碼，瀏覽器便會停止剖析並下載該資源。每次轉譯都會增加網路來回行程，這會延遲第一次轉譯網頁的時間。

因此，算繪不需捲動位置區域所需的 JavaScript 和 CSS 應該內嵌，而在 ATF 內容傳送完成後，JavaScript 或 CSS 則應在網頁中加入額外功能的 JavaScript 或 CSS。

(5) 為瀏覽器的配置和轉譯工作預留時間 (200 毫秒)
剖析 HTML、CSS 及執行 JavaScript 的過程也會耗費時間和用戶端資源！視行動裝置的速度和網頁的複雜而定，這個過程可能需要數百毫秒。建議您預留 200 毫秒做為瀏覽器負擔。
(6) 最佳化 JavaScript 的執行和轉譯時間
執行複雜的指令碼和效率不佳的程式碼，可能需要數十毫秒、數百毫秒。請使用瀏覽器內建的開發人員工具分析及最佳化程式碼。如需詳細介紹，請參閱 Chrome 開發人員工具互動式課程。

常見問題

如果使用 JQuery 這樣的 JvaScript 程式庫，有什麼建議嗎？
許多 JavaScript 程式庫 (例如 JQuery) 都可用來強化網頁功能，為網頁增添互動性、動畫和其他效果。不過，這些行為大多可以在 ATF 內容轉譯後再安全加入。請研究將這些 JavaScript 的執行和載入移動，直到網頁載入之後。
如果使用 JavaScript 框架來建構網頁，有什麼建議嗎？
如果網頁內容是由用戶端的 JavaScript 建構，建議您調查內嵌相關 JavaScript 模組，以避免額外的網路往返。同樣地，利用伺服器端轉譯功能可大幅改善第一個網頁載入的效能：在伺服器上算繪 JS 範本、將結果內嵌至 HTML，並在應用程式載入後使用用戶端範本。
如何識別頁面中的關鍵 CSS？
在 Chrome 開發人員工具中開啟「稽核」面板，然後執行「網頁成效報表」，然後在產生的報表中找出「移除未使用的 CSS 規則」。或者，您也可以使用任何第三方工具或指令碼來識別每個頁面所套用的 CSS 選取器。
可以將這些最佳做法自動化嗎？
當然可以！有很多商業的或開放原始碼的網頁效能最佳化 (WPO) 產品都可以幫助您達成上述部分或全部標準。如需開放原始碼解決方案，請參閱 PageSpeed 最佳化工具。
如何調整伺服器才能符合這些標準？
首先，請確認伺服器搭載的作業系統是最新版本。您必須具備 Linux 核心 2.6.39 以上版本，才能受惠於增加的初始 TCP 壅塞視窗大小 (IW10)。如為其他作業系統，請參閱說明文件。
如要改善伺服器回應時間，請檢測程式碼，或使用應用程式監控解決方案找出瓶頸，例如指令碼執行階段、資料庫呼叫、遠端程序呼叫 (RPC) 要求、轉譯等。我們的目標是在 200 毫秒內轉譯 HTML 回應。
內容安全性政策 (CSP) 該怎麼ㄅㄢ？
如果您使用 CSP，可能需要更新預設政策。
首先，在 HTML 元素(例如< p style=...>)。如果您有內嵌的 JavaScript，那麼您必須更新 CSP 政策，指定其使用指令碼雜湊或 Nonce，或是使用「unsafe-inline」，讓所有內嵌指令碼得以執行。如果您有內嵌樣式，CSP 政策必須更新為使用樣式雜湊或 Nonce，或是使用「unsafe-inline」，讓系統處理所有內嵌樣式區塊。

還有其他問題嗎？歡迎在我們的 pagespeed-insights-discuss 討論群組內提問及提供意見。

意見回饋

本頁內容對你是否有幫助？