Google 網站測速怎麼測？PageSpeed Insights 使用教學詳解

網站開啟速度慢，很多站長第一反應都會想到用 Google 測一下。Google 自己提供的 PageSpeed Insights，就是目前比較常用的網頁效能檢測工具之一。輸入網址後，不僅能看到行動版和桌面版的效能評分，還可以檢查 LCP、INP、CLS 等 Core Web Vitals 指標，以及圖片、JavaScript、CSS、伺服器回應等方面的問題。

不過，PageSpeed Insights 給出的「90分」「100分」，並不能簡單理解成網站實際開啟速度。它更擅長分析網頁本身的載入和互動效能。如果想知道網站在不同地區、不同電信網路下到底快不快，還需要結合其他網路測速結果一起判斷。

下面就從實際使用出發，看看 Google 網站測速應該怎麼測，以及 PageSpeed Insights 裡的各項數據到底應該怎麼看。

一、Google PageSpeed Insights 是什麼？

Google PageSpeed Insights，通常簡稱 PSI，是 Google 提供的一款網頁效能分析工具。只要輸入需要檢測的網頁地址，就可以分別查看行動裝置和桌面裝置下的效能情況。

PageSpeed Insights 主要會提供兩類資訊：

一類是來自真實 Chrome 使用者造訪產生的實測數據，也就是 CrUX 數據；另一類是透過 Lighthouse 在固定測試環境中執行得到的實驗室數據。前者更接近真實使用者過去一段時間的造訪體驗，後者則更適合查找目前頁面具體存在哪些效能問題。Google 官方目前說明，PSI 中的真實使用者體驗數據統計的是過去 28 天的數據。

所以，PageSpeed Insights 並不只是簡單告訴你「這個網頁用了幾秒開啟」，而是從頁面載入、互動回應、視覺穩定性等多個角度判斷網頁體驗。

對於做 Google SEO、獨立站、跨境電商或內容網站的人來說，它最大的價值其實不是那個分數，而是幫助找到頁面到底慢在哪裡。

二、Google 網站測速怎麼測？

使用 PageSpeed Insights 做 Google 網站測速並不複雜，整個過程基本幾分鐘就能完成。

1. 開啟 Google PageSpeed Insights

進入 Google PageSpeed Insights 官網，在輸入框中填寫需要測試的網頁地址。

測試時建議填寫完整 URL，例如：

https://www.example.com/

如果要測試某個具體的產品頁、文章頁或落地頁，也可以直接輸入對應頁面地址。

很多人測試網站速度時只測首頁，這其實不太夠。

首頁速度正常，不代表網站裡面所有頁面都正常。產品頁可能載入更多商品圖片，文章頁可能存在廣告腳本，登入頁可能需要請求多個介面，不同頁面的前端資源和伺服器請求差異很大，最終的測速結果自然也會不同。

如果是一個比較重要的網站，至少建議分別測試首頁、主要內容頁和核心轉換頁面。

2. 點擊「分析」

輸入網址以後點擊「分析」，PageSpeed Insights 會開始抓取並檢測目前頁面。

測試完成後，會產生一份完整的效能報告。

如果頁面無法正常存取、伺服器回應異常，或網站對 Google 的檢測請求進行了限制，也可能出現測試失敗的情況。這種時候不要急著認為是 PageSpeed 本身出錯，可以先確認目標網頁是否能夠正常從公開網路存取。

3. 分別查看行動版和桌面版

PageSpeed Insights 會分別展示行動裝置和桌面裝置的測試結果。

這兩個結果經常不一樣。

例如一個網站桌面版可能有 92 分，行動版只有 58 分，這並不罕見。電腦的處理能力、網路環境和手機不同，而行動版測試通常更容易暴露 JavaScript 執行時間過長、首屏圖片過大或頁面資源過多的問題。

因此，做 Google 網站測速時，不要只看到桌面版變綠就結束測試。

如果網站大部分流量來自手機，行動版結果反而更值得優先關注。

三、PageSpeed Insights 測速結果怎麼看？

第一次開啟 PageSpeed Insights 報告，最容易出現的問題就是數據很多，卻不知道先看什麼。

實際上沒必要一項一項從頭研究。先把報告分成「真實使用者數據」和「實驗室數據」兩個部分，會容易理解得多。

1. 真實使用者體驗數據

如果目前網頁有足夠的真實造訪樣本，PageSpeed Insights 會顯示真實使用者體驗數據。

這些數據來自 Chrome User Experience Report，也就是 CrUX。

它反映的不是剛才這一次測試，而是實際 Chrome 使用者在不同裝置、不同網路環境中造訪頁面時累積下來的體驗數據。目前 PSI 展示的是過去 28 天的數據，並使用第 75 百分位的數據進行判斷。

這一部分主要適合回答一個問題：真實使用者造訪這個頁面時，體驗到底怎麼樣？

其中經常會看到：LCP；INP；CLS；FCP；TTFB。

尤其是 LCP、INP 和 CLS，它們屬於目前 Google Core Web Vitals 的三個核心指標。

需要注意的是，並不是所有網頁都會顯示真實使用者數據。

如果網站剛上線、頁面流量比較少，或 Chrome 收集到的樣本不足，PageSpeed Insights 可能不會顯示對應頁面的真實數據，有時會退回到整個網域級別的數據；如果整個網站數據量仍然不足，就可能直接顯示沒有足夠的真實使用者數據。

這並不代表網站存在故障，只是目前數據量不足。

2. 實驗室數據

實驗室數據主要由 Lighthouse 在模擬環境中測試得到。與真實使用者數據不同，它更適合定位目前頁面的問題。

例如報告中可能發現：圖片體積過大、JavaScript 執行時間太長、CSS 阻塞頁面渲染、伺服器初始回應慢，或頁面存在大量沒有使用的前端資源。

簡單來說，兩類數據可以這樣理解：

所以，如果真實使用者數據比較差，可以先確認「問題確實存在」；再透過 Lighthouse 的實驗室報告繼續往下找原因。

四、PageSpeed Insights 多少分算正常？

PageSpeed Insights 最顯眼的通常是頁面上方的 Performance 效能評分。

目前 Lighthouse 的效能評分劃分方式為：

90 分以上通常會顯示為綠色，50～89 分顯示為橙色，49 分及以下則顯示為紅色。

但這裡有一個很容易被誤解的問題：PageSpeed 不是越接近 100 分，網站就一定越快。

Google 自己也提到，要做到 100 分並不容易，而且並不現實。一個已經達到 95 分的網站，繼續投入大量開發時間衝到 100 分，實際使用者可能根本感受不到明顯區別。

相比之下，如果一個網站只有四五十分，又明顯存在首屏載入慢、互動卡頓等問題，把這些主要瓶頸處理掉，實際效果通常會更明顯。

所以看 PageSpeed 報告時，不建議只盯著那個圓圈裡的數字。

分數可以作為一個快速參考，但真正應該看的是：到底哪幾個指標拖慢了頁面，以及這些問題有沒有影響真實使用者。

五、Google 網站測速最重要的三個指標怎麼看？

目前 Google Core Web Vitals 主要由 LCP、INP 和 CLS 三項指標組成，分別對應載入速度、互動回應和頁面穩定性。

1. LCP：頁面主要內容多久顯示出來

LCP，全名 Largest Contentful Paint，可以簡單理解成：使用者開啟網頁以後，頁面最主要的內容什麼時候真正出現在螢幕上。

例如一個產品頁面，首屏最大的商品圖片可能就是 LCP 元素；文章頁面中，一張大封面圖或大標題區域也可能成為 LCP 元素。

目前建議的判斷標準是：

如果 LCP 很高，常見原因包括首屏圖片太大、伺服器回應慢、字型載入慢，以及 CSS 或 JavaScript 阻塞頁面渲染。

2. INP：使用者操作以後頁面反應快不快

INP，全名 Interaction to Next Paint。它關注的是使用者和頁面發生互動以後，網頁能不能及時做出反應。例如點擊導覽選單、點擊篩選按鈕、展開一個內容區域，如果使用者點下去以後頁面明顯卡住一會兒才有反應，INP 就可能比較高。

目前建議標準為：

INP 不好時，通常需要重點檢查 JavaScript 執行、主執行緒任務和複雜互動邏輯。

3. CLS：頁面載入過程中會不會亂跳

CLS，全名 Cumulative Layout Shift，主要衡量頁面視覺穩定性。

比較典型的情況是：

文章剛開啟時你準備點擊一個按鈕，突然上方載入出一張廣告圖片，把原來的按鈕整個往下推，結果點錯了位置。

這種頁面內容在載入過程中突然發生位移的現象，就是 CLS 重點檢測的問題之一。

目前建議標準為：

對於圖片、影片、iframe 或廣告位，提前設定好寬高尺寸，通常可以減少很多不必要的版面位移。

六、為什麼 PageSpeed 分數很高，網站實際開啟還是慢？

有些網站 PageSpeed Insights 已經能跑到 90 多分，但是國內使用者開啟還是覺得慢；還有一些網站前端資源已經壓縮得很好，實際造訪卻經常需要等很久。

原因在於：PageSpeed Insights 衡量的頁面效能，並不等於使用者和伺服器之間完整的網路品質。

使用者真正造訪一個網站時，還會受到很多因素影響，例如伺服器所在地區、電信線路、DNS 解析、網路延遲、封包遺失、跨境出口、CDN 節點以及回源線路。

例如一個網站伺服器部署在美國，頁面本身已經做得非常輕，JavaScript 和圖片也最佳化得不錯，PageSpeed 測出來可能很好看。

但如果主要造訪使用者在中國大陸，數據仍然要經過較長的跨境網路鏈路。一旦晚高峰國際出口擁塞或部分地區存在線路繞路，真實使用者依然可能感覺網站很慢。

這種問題單看 PageSpeed 很難判斷。

如果還想繼續確認網站在國內不同地區、不同電信中的造訪情況，可以再用 Chahu 做一次多節點網站測速。輸入網站地址後直接測試全國三網節點，重點看不同地區之間是否存在明顯的回應時間差異。

如果 PageSpeed 表現正常，但部分中華電信、遠傳或台灣大哥大節點明顯偏慢，排查方向就應該從前端程式碼轉向網路線路、CDN、伺服器位置或電信鏈路。

反過來，如果各地網路回應都比較穩定，但 PageSpeed 的 LCP、INP 等指標仍然很差，那麼問題更可能出在頁面本身。兩種測試結合起來，比只盯著一個 PageSpeed 分數更容易找到真正原因。

七、PageSpeed Insights 常見問題怎麼最佳化？

PageSpeed Insights 會列出很多最佳化建議，不過並不是每一條都需要立刻處理。實際最佳化時，可以先從影響比較明顯的問題開始。

1. 圖片載入時間過長

圖片通常是網頁中佔用流量比較大的資源之一，尤其是產品站、電商站和圖片較多的內容網站。

如果首屏直接載入幾 MB 的高畫質圖片，很容易拖慢 LCP。

可以優先檢查圖片尺寸是否遠大於實際顯示尺寸，並對圖片進行壓縮。條件允許的情況下，也可以使用 WebP、AVIF 等格式，同時對非首屏圖片啟用延遲載入。

需要注意的是，首屏核心圖片不能一味全部延遲載入，否則反而可能讓主要內容出現得更晚。

2. JavaScript 檔案過多

現在很多網站安裝一個統計工具、客服系統或行銷外掛，都會繼續往頁面裡增加 JavaScript。

外掛裝得越來越多以後，經常出現網頁看起來沒有增加多少內容，但瀏覽器需要執行的腳本越來越重。

如果 PageSpeed 報告提示 JavaScript 執行時間過長，可以檢查是否存在已經不用的外掛、重複載入的腳本，以及一些沒必要在首屏立即執行的第三方程式。

能刪除的先刪除，需要保留但不影響首屏的，可以考慮延遲載入。

3. CSS 阻塞頁面渲染

CSS 檔案比較多或載入方式不合理，也會影響頁面首屏顯示。

如果報告一直提示存在渲染阻塞資源，可以檢查是否載入了大量實際頁面根本沒有使用的 CSS。

有些網站使用大型主題或頁面編輯器，一個簡單頁面也會把整個主題的樣式檔案載入進來。這種時候單純壓縮檔案效果有限，更重要的是減少不必要的資源。

4. 伺服器回應時間過長

如果前端已經最佳化得不錯，但伺服器遲遲不能回傳第一批數據，網頁同樣快不起來。

這種情況下要繼續檢查伺服器負載、資料庫查詢、動態程式、快取命中率以及 CDN 回源情況。

尤其是 WordPress、商城和動態內容較多的網站，後端回應時間經常比圖片壓縮更值得優先解決。

5. 頁面版面位移嚴重

如果 CLS 較高，可以重點檢查那些後載入進來的元素。

常見的包括廣告位、圖片、影片、iframe、Cookie 提示以及動態推薦內容。

比較有效的方式，是提前給這些元素預留空間，而不是等資源載入完成以後再突然把頁面撐開。

八、Google 網站測速只看 PageSpeed Insights 夠不夠？

如果只是想檢查網頁前端效能，PageSpeed Insights 已經能提供很多有價值的資訊。

但如果想完整判斷「網站為什麼慢」，只看它還不夠。

不同工具解決的是不同層面的問題：

實際排查網站速度問題時，更實用的方法不是追求某一個工具裡的「滿分」，而是先確定問題到底發生在哪一層。PageSpeed Insights 分數低，可以繼續檢查圖片、JavaScript、CSS、伺服器回應和 Core Web Vitals；PageSpeed 表現很好，但真實使用者仍然回報造訪慢，就應該把注意力放到地區、電信、DNS、網路線路、CDN 和源站位置上。

Google 網站測速的價值也在這裡。它可以幫你判斷頁面本身是否存在明顯的效能瓶頸，但網站真正快不快，最終還是要回到使用者實際造訪環境中驗證。把 PageSpeed Insights 的頁面效能分析和多節點網路測速結合起來，通常比單獨看一個效能分數更容易找到問題，也更接近使用者真正感受到的網站速度。

常見問題

Q1：PageSpeed Insights 測出來的分數低，真的會直接影響 Google SEO 排名嗎？

A： Google 官方明確過，那個「圓圈裡的分數」本身並不是排名的直接指標，真正影響排名的是 Core Web Vitals（核心網頁指標）的實際表現。只要你的 LCP、INP 和 CLS 數據能落在「良好」區間（通常對應報告裡的綠色區間），就算 Performance 總分只有 70-80 分，也不會因為速度問題被 Google 扣分。不用為了湊滿 100 分去過度最佳化。

Q2：網站剛上線，LCP（最大內容繪製）時間一直過長，最快的分步排查思路是什麼？

A： 先看 PSI 報告裡拿哪一個元素當成了 LCP（通常是首屏的大圖、輪播圖或大標題）。排查步驟一般是：第一步，看這張圖有沒有做體積壓縮，格式是不是 WebP/AVIF；第二步，檢查有沒有對首屏圖片誤用了延遲載入（Lazy-loading）；第三步，如果圖片沒問題，看一下伺服器 Response Time（TTFB）是不是拖了後腿。

Q3：INP 總是顯示橙色或紅色，一般怎麼解決？

A： INP 變差大多是 JavaScript 佔用了瀏覽器主執行緒導致的。當使用者點擊選單、篩選框時，瀏覽器忙著跑背景腳本，沒空回應使用者的操作。常見的解決方法包括：刪掉不常用的行銷/統計腳本、延遲載入非首屏需要的第三方外掛，或找前端開發最佳化長任務（Long Tasks）。

Q4：頁面載入時總是有東西「跳一下」，CLS 指標怎麼最佳化最有效？

A： CLS（累積版面位移）最怕後載入出來的資源把前面的內容推開。最有效的解決辦法是在 CSS 裡給所有圖片、Banner 廣告位、影片框提前設定好具體的寬高比例（Aspect Ratio）或佔位空間。這樣就算圖片還沒載入出來，位置已經留好了，頁面就不會來回抖動。

Q5：做 SEO 最佳化時，到底應該測首頁，還是測具體的文章頁、產品頁？

A： 建議抽樣測試。首頁通常結構最複雜、外掛最多，測試價值高；但轉換頁和高流量文章頁才是真實吸引使用者的地方。文章頁可能因為有很多高畫質插圖導致 LCP 超標，產品頁可能因為有很多變體選擇導致 JS 過重。把首頁、核心產品頁、高流量文章頁各拿一個出來測，結果才全面。