PageSpeed Insights是什麼？分數看不懂?一次搞懂網站速度檢測

如果你剛用 Google 的 PageSpeed Insights 測完自家網站,看到一個像是 52 分、67 分這樣的數字,心裡大概會冒出兩個念頭:這個分數到底代表什麼,還有,我是不是該緊張了。

先講清楚一件事:PageSpeed Insights(常被簡稱 PSI)不是一套需要評估要不要花錢導入的系統,而是 Google 提供的免費公開檢測工具——任何人只要有一個網址,就可以直接上網測試,不需要付費、不需要申請帳號、也不用先跟廠商談方案。它會分別針對「行動版」與「電腦版」跑出一個 0 到 100 的綜合分數,並附上一份建議清單,列出哪些地方可能拖慢了這個網頁。正因為它是任何人都能免費使用的通用工具,理解「這個分數代表什麼、該怎麼解讀」比糾結「要不要用」重要得多。

這篇文章會照著多數人第一次看到分數時會問的問題,一步步講清楚:這個分數怎麼算出來的、幾分才算正常、Core Web Vitals 這三個常被提到的英文縮寫到底在測什麼,還有分數不理想時,實際上可以怎麼處理。

PageSpeed Insights 到底在測什麼

PageSpeed Insights 測的是「一個網頁在使用者眼中跑起來順不順」,而不是單純的伺服器回應速度。Google 官方對這個工具的說明是,它會回報一個網頁在行動版與電腦版的實際使用者體驗表現,並針對單一網頁分析後,提供具體的改善建議。

這裡有一個多數人容易誤會的地方:PSI 的分數不是單一種資料來源算出來的,而是「實驗室測試資料」加上「過去 28 天真實使用者的資料」混合而成。實驗室資料是 Google 用模擬環境跑出來的技術檢測結果,適合用來抓問題根源;真實使用者資料則是實際訪客用不同裝置、不同網路環境瀏覽網站時回傳的體感資料,更貼近「真人打開網站的感受」。Google 官方部落格對這一點說得很直接:

「PageSpeed Insights 的分數結合了實驗室測試資料與過去 28 天的真實使用者資料,兩者用途不同——實驗室資料用於找出問題根源,真實使用者資料反映的是實際訪客的體感。」

— Google Search Central Blog《Real-world data in PageSpeed Insights》

這也解釋了一個常見的困惑:「我明明已經把網站改快了,為什麼分數還沒變?」答案是,真實使用者資料是過去 28 天的滾動平均,不會因為今天改完程式碼就馬上反映在分數上,通常需要等一段時間累積新的訪客資料,分數才會跟著調整。

測試方式很簡單:打開 pagespeed.web.dev,貼上網站網址,按下分析,系統會分別跑出行動版與電腦版兩組結果。多數企業網站在行動版的分數會比電腦版低,這是正常現象,因為手機的運算能力與網路條件本來就比較嚴苛,Google 的評分標準也是照這個現實情況去設計的。

分數怎麼分級?幾分才算及格

PageSpeed Insights 的分數區間分成三個等級:90 到 100 分屬於良好、50 到 89 分屬於待改善、0 到 49 分屬於偏差。

如果分數落在 50 到 89 分這個區間,不代表網站有嚴重問題,而是還有一些具體可以優化的空間;如果分數低於 50 分,通常表示網站在圖片、程式碼或伺服器層面有比較明顯的效能瓶頸,值得花時間處理。

從 SEO 操作的實務角度來看,多數討論會建議把分數顧到 80 分以上,作為一個「使用者體驗不至於扯後腿」的基本水位;如果進一步想追求更好的使用者體驗,90 分以上會是比較理想的目標。但這裡要老實說一句:分數是根據真實使用者資料動態計算的,每天都可能因為訪客的裝置組合、網路狀況不同而有些微波動,100 分在多數真實營運中的網站上其實很難長期維持,也沒有必要把它當成唯一目標。與其糾結在個位數的分數差異,不如把心力放在下面會談到的 Core Web Vitals 三項核心指標上,那才是真正影響使用者體驗的關鍵。

下面這個表格整理三個分數區間對應的意義與建議行動,可以先抓一個大方向:

分數區間	等級	代表意義	建議行動
90–100	良好	頁面載入與互動體驗接近理想狀態	定期複測即可,不必刻意再壓榨分數
50–89	待改善	有明確可優化的空間,但不算嚴重問題	依報告中的「機會」與「診斷」項目排優先順序處理
0–49	差	效能瓶頸明顯,可能影響使用者實際體感	建議先確認圖片、外掛與主機資源三個常見根因,必要時尋求技術評估

Core Web Vitals 三指標:LCP、INP、CLS 是什麼

Core Web Vitals 是 Google 用來衡量「真實使用者體驗」的一組核心指標,涵蓋載入效能、互動反應與視覺穩定性三個面向,也是 PageSpeed Insights 報告中最重要的三個數字。Google 官方技術文件 web.dev 對這三項指標的門檻值有明確定義:

「LCP 應在頁面開始載入的 2.5 秒內完成;INP 應低於 200 毫秒;CLS 應低於 0.1,三者皆達標才算『良好』等級。」

— Google web.dev《Vitals》

LCP(最大內容繪製,Largest Contentful Paint):測量頁面主要內容(通常是主圖或大段文字)出現在畫面上所花的時間。

INP(下一次繪製互動,Interaction to Next Paint):測量使用者點擊、觸控頁面後,瀏覽器多快能給出視覺反應。這個指標是 2024 年正式取代舊指標 FID(首次輸入延遲)之後才成為 Core Web Vitals 正式成員的,如果看到還在用 FID 當標準的文章,那多半是比較舊的資料,現在應該以 INP 為主。

CLS(累積版面配置位移,Cumulative Layout Shift):測量頁面載入過程中,畫面元素(例如圖片、廣告區塊)有沒有無預警地跳動位移,讓使用者點錯按鈕或閱讀被打斷。

這三項指標為什麼重要?因為 Google 官方文件明確指出,Core Web Vitals 是衡量真實使用者體驗的一組信號,與網頁在搜尋結果的呈現有關——但這裡要特別澄清一個常見的過度簡化說法:Core Web Vitals 不是「分數衝到 90 分,排名就會往上衝」這種直接因果關係,而是使用者體驗信號的其中一環,跟內容品質、搜尋意圖符合度等其他因素一起被納入考量。把它當成「值得優化的體驗指標」,會比當成「排名保證」更貼近實際狀況。

為什麼分數可能不好看

多數企業網站分數不理想,原因通常集中在幾個地方,依常見程度排列:

第一,圖片沒有壓縮或格式老舊。高解析度的產品圖、banner 圖如果沒有適當壓縮或轉成現代圖片格式,往往是拖慢 LCP 最直接的原因。第二,外掛與第三方腳本疊加過多。尤其是用 WordPress 這類 CMS 架站的網站,長期累積的外掛、行銷追蹤碼、聊天客服工具,每多一個都會增加瀏覽器需要處理的資源,直接影響 INP 與整體載入時間。第三,主機資源不足或伺服器回應時間過長,這屬於架構層面的限制,不是單靠壓縮圖片就能解決。第四,版面元素載入順序沒有妥善安排,導致廣告、圖片或字型載入時畫面跳動,影響 CLS。

值得一提的是,如果網站架在電商平台或某些制式系統上,分數表現常常會受到平台本身架構的限制——這種情況下能自己調整的空間有限,重點會變成「先處理自己能控制的部分(圖片大小、不必要的外掛),架構層的限制則需要評估是否值得投入資源改善」,而不是糾結在平台限制不了的地方。

跟 GTmetrix、Lighthouse 分數不一樣,該信哪個

這是另一個很常見的疑惑:同一個網站,在 PageSpeed Insights 測出來是 65 分,丟到 GTmetrix 卻變成不同的等級或數字,兩邊對不上,不知道該相信哪一個。GTmetrix 官方部落格對這個現象有清楚的說明:

「PSI 與 GTmetrix 都以 Google 的 Lighthouse 為技術基礎,但實作方式不同——PSI 混合了模擬測試環境與真實使用者的 CrUX 資料,GTmetrix 則用實際瀏覽器在指定伺服器地點做觀測式測試,兩者分數不同是正常現象。」

— GTmetrix 官方部落格《GTmetrix vs PageSpeed Insights (PSI)》

換句話說,兩個都對,只是回答的問題不一樣。PSI 反映的比較接近「一般使用者的真實感受」,適合拿來當作網站體質健檢的第一步,快速掌握大方向;GTmetrix 則比較適合在已經知道要優化、需要更細節的技術診斷時使用,例如查看請求瀑布流、下載頁面載入過程的錄影。兩者分數不一樣,不代表其中一個測錯了,而是本來就在回答不同的問題,不需要為了「該信哪個」而糾結。

一定要衝到100分嗎

不用。這點值得特別說清楚,因為市面上不少內容把「100分」講得像是一個必須達成的終極目標,但這既不符合 Google 官方的立場,也常常讓網站經營者做出不必要的取捨。

PageSpeed Insights 的分數是根據真實使用者資料動態計算,使用者的裝置、網路狀況每天都在變化,100 分在多數真實營運的網站上很難穩定維持,國際技術社群也普遍認為沒有必要為了衝滿分而犧牲網站原本該有的功能或內容豐富度。比較務實的做法是:先確保 Core Web Vitals 三項指標都落在「良好」等級,分數自然就會落在不錯的區間,不需要另外去斤斤計較個位數的分數差異。

真正該在意的,反而是「分數突然大幅下滑」這種變化——如果過去都維持在 80 分上下,某次改版後掉到 40 幾分,這種明顯的退步才是需要優先排查的訊號,而不是在 85 分跟 92 分之間反覆糾結。

分數不好,接下來可以怎麼做

如果測完發現分數落在待改善甚至偏差的區間,可以照這個順序處理:第一步,展開報告裡的「機會」與「診斷」區塊,這裡會列出對這個頁面影響最大的具體項目,例如「壓縮圖片可節省多少載入時間」,照影響力大小排序處理。第二步,優先處理圖片優化與會阻擋畫面繪製的資源載入問題,這兩項通常對 LCP 的改善最明顯。第三步,檢視主機的回應速度,流量成長但主機規格沒跟上,是很多老網站分數退步的常見原因。第四步,精簡 JavaScript 與盤點第三方腳本,把不再需要的行銷工具、追蹤碼移除。第五步,才是處理版面穩定性與字型載入這類相對細節的項目。

如果初步排查後發現問題出在網站架構本身——例如主機規格明顯不足、外掛與系統疊得太複雜、前端程式碼老舊到難以局部調整——這種情況通常不是靠自己微調參數就能解決。這時候比較實際的做法,是找專業的技術團隊評估整體架構現況,釐清問題出在哪個層面、值不值得投入改版,而不是持續在同一批外掛設定裡打轉。瞻新資訊在協助客戶處理網站建置與優化時,常遇到的情況正是「單點優化已經做到底,但架構本身撐不住」,這種時候討論的重點會是把問題根源說清楚、評估合理的處理方式,而不是一味追求分數本身好看。

FAQ