【2026 網站速度優化指南】測試分數高為何用戶仍覺得慢？Core Web Vitals 指標解讀 【2026 網站速度優化指南】測試分數高為何用戶仍覺得慢？Core Web Vitals 指標解讀

檢測工具與三項核心指標

網頁載入速度測試工具之中，Google 的 PageSpeed Insights 免費可用，輸入網址即可。報告主欄是 Lighthouse 模擬測試；在資料足夠時，另附來自 Chrome 真實用戶的 CrUX 資料，反映過去 28 日的實際瀏覽，手機與桌面分開計算。流量未夠的網址，可能只見到整個網站層級的資料，甚至沒有真實訪客一欄：空白不等於合格，只代表未有可供評估的 CrUX 資料。

判讀速度，主要看 Core Web Vitals 三項指標，各自對應載入、互動與版面穩定。按Google 的 Web Vitals 文件，良好水平以各項指標第 75 百分位的頁面瀏覽紀錄判定。個別指標資料不足時另有處理，例如 PSI 在 INP 資料不足時，可只按 LCP 與 CLS 評估。

兩個讀法容易出錯。LCP 量的是可視範圍內最大內容出現的時間，不是整頁完全下載。每頁的 LCP 因此各自不同，判斷案例頁要測該頁，不能用首頁成績代替。另一個是測試方式的界線：標準的頁面載入式 Lighthouse 測試沒有實際互動，報告不會直接給 INP，要靠 TBT（總阻塞時間）一類指標輔助推斷。

PageSpeed Insights 同時列出模擬測試與真實訪客數據

測試數據與訪客情境為何對不上

模擬測試在指定裝置、網絡與地點的受控環境執行，條件容易保持一致，適合比較改動前後，但結果仍會波動，比較時要核對報告的測試環境。真實訪客不是這樣上站的：裝置有新有舊，網絡有光纖有流動，地區、登入狀態與操作各異，頁面的工作量人人不同。Google Chrome 團隊在兩類數據差異的說明講得清楚，單一分數不能代表所有訪客的體驗。

同一頁大量高清圖，桌面寬頻壓力不大，用流動網絡的手機訪客就要逐張等；同一支舊手機，應付文字頁有餘，應付塞滿輪播與腳本的首頁就吃力。收到「很慢」的反映，先記下網址、裝置、網絡、登入狀態與卡住的操作，按相同條件重現，分清是內容未出現，還是操作沒有回饋；「外國主機所以慢」一類判斷，未經重現驗證之前都只是猜測。

圖片與媒體

未經壓縮的原始相片直接上載，會令頁面重量大增，一張的大小隨時超過整頁文字的總和。假設裝修公司的案例頁放了大量這類相片，訪客未讀到第一段文字，瀏覽器已在下載過量的資料。

處理有次序：先壓縮，適當壓縮後肉眼分別通常不大，檔案卻小得多，之後檢查相片細節與圖中文字；再轉格式，WebP、AVIF 一類現代格式在同樣畫質下一般更細，主流瀏覽器已支援，轉換後比較實際檔案大小；最後按顯示尺寸與裝置像素密度輸出合適版本。圖片壓縮、格式與尺寸的逐步做法，另見〈網站圖片加速〉。

影片與音訊重量更高。首頁自動播放影片可改為先載入封面圖、按播放才載入影片。嵌入的第三方影片可評估點擊後才載入播放器的做法，有否現成設定視乎平台，部分情況要調整嵌入方式。不做點擊載入的話，至少保留清晰的文字連結作為後備；改用點擊載入之後，若影片是要被搜尋發現的主要內容，另要核對 Google 渲染後讀到什麼。

程式碼與第三方資源

部分 CSS 要先處理完，瀏覽器才畫出畫面；大型 JavaScript 亦要下載、解析、執行之後，頁面才完全可用。這些工作排在訪客見到內容之前，就是阻塞渲染；檔案越多越大，訪客見到內容就越遲。

對應做法是把「現在就要」與「稍後才要」分開：關鍵樣式留下，其餘延後；合適的外部腳本可用 defer，避免下載時阻塞 HTML 解析。按MDN 對 defer 的定義，腳本會在文件解析完成後、DOMContentLoaded 前執行，不是保證先繪製畫面，執行時的工作量仍要控制。改版幾次後留下、已無人使用的舊程式碼，確認沒有依賴之後移除。

另一種負擔來自外掛與第三方資源：統計、對話插件、社交嵌入、字型服務，各有自己的腳本、請求與伺服器，其中腳本的解析與執行會佔用瀏覽器的主執行緒，拖慢操作的回應。審視有步驟：列出頁面用到的外掛、用途與載入位置；非必要項目在測試環境停用前後各重測一次，並覆核表單、付款與統計是否正常，再決定去留。

主機與資料庫

TTFB（首字節時間）量度由訪客發出請求到收到第一個位元組的整段等待，涵蓋網絡與連線路程、轉址，以及伺服器接收請求、查詢資料庫、組好頁面的處理。Google Chrome 團隊的Optimize TTFB 說明把可查的位置拆成寄存資源、應用程式與資料庫；TTFB 偏高時，網絡與轉址同樣在排查之列。

排查可以逐項看：寄存方案是否追得上現時流量、PHP 等版本是否多年未升、資料庫查詢是否隨內容增加而變慢，這些都是改圖片改不到的位置。有人會想先加 CDN。CDN 把可快取的回應放到較接近訪客的節點，頻繁更新的內容也有合適的快取與邊緣處理做法；但它代替不了應用程式與資料庫的優化，個人化回應亦不可直接共用。寄存服務的介紹（SSD 儲存、Git、備份、隔離空間等），可看〈網頁寄存服務〉。

快取與 CDN

快取的原理是重用：同一份回應，不必每次重新下載、重新處理。按MDN 的 HTTP 快取文件，快取分為私人與共用兩大類，瀏覽器屬前者，CDN 是共用快取的一種；可否重用，視回應的規則與命中情況而定。

設定上有兩個易錯位。其一，登入狀態、購物車、會員價一類個人化回應，要明確訂快取規則，不能讓共用快取把甲訪客的資料送給乙訪客。其二，快取與更新要配合：快取期太長，改版後訪客見到的可能還是舊檔；太短，重訪又享受不到節省。改版或更新外掛之後，值得重看一次這組設定。

原理與實作方式

延遲載入（Lazy Loading）讓瀏覽器先載入訪客眼前的內容，其餘等到接近可視範圍才開始下載。一頁幾十張圖，訪客初見的畫面其實只需要頂部幾張，下方內容的傳輸全部延後。按Google 的開發文件，瀏覽器通常在內容接近可視範圍時已提前載入，不是等訪客捲到看見那一刻。

實作比想像中簡單。現代瀏覽器原生支援圖片的 loading="lazy"，在 img 標籤加上屬性就完成；iframe 有對應寫法，嵌入的地圖與影片適用；要自行控制觸發條件的進階實作，多數用 Intersection Observer API。兩個細節：eager 是正常載入，不是加速開關；CSS 背景圖用不到這個原生屬性，要另外處理。

首屏界線與版面穩定

首屏範圍內的圖片（即訪客未捲動前見到的部分），連同作為 LCP 的圖片，保持正常載入；LCP 圖片必要時提高資源優先次序。首屏以外的圖片，按重要性與資源類型選擇，非即時需要的才延遲，不是一律套用。以裝修公司的案例頁為例，頂部代表相正常載入，下面幾屏的圖庫延後，第一眼觀感不受影響。手機與桌面首屏範圍不同，做手機網站速度優化時，界線要兩邊各自確認。

另一件事是預留空間。每張圖先寫好 width 與 height，或用相應比例，載入前版面已留位，該圖引起的位移就減少；至於整頁的 CLS 是否合格，還要計其他動態內容，預留空間不是全頁保證。

首屏界線按裝置各自劃定

延遲載入會影響 SEO 嗎？

按官方建議實作，內容一般讀得到。Google 的檢索器不會像人一樣捲動與點擊，Google Search Central 的指引講明：重要內容不能只靠點擊等訪客動作才載入，以進入可視範圍為觸發的延遲載入，屬於讀得到的做法。

實作後仍要驗證：在 Search Console 的網址檢查查看「渲染後的 HTML」，搜尋該段文字是否在其中；圖片與影片則核對 src 有沒有實際網址。見不到，表示 Google 該次測試未取得該內容，不能就此斷定真人也看不到。先檢查載入方式與資源能否取得，再重測。期待也要正確：延遲載入是改善載入的工具，Google 沒有承諾它會直接提升排名。

等待提示與進度回饋

空白最令訪客不安：不知道網站在載入、當機，還是已經離開。一個轉圈、一句「載入中」，都在告訴訪客系統在工作，等待由不明變成可預期。選擇有原則：短等待用轉圈就好；進度條要有實際可表示的進度才用，不能因為等待長就放一條假百分比；多步流程如預約、結帳，顯示訪客目前在第幾步，他們至少知道流程仍在前進。介面與互動設計上減少訪客流失的做法，另見〈UI/UX 設計降低跳出率〉。

骨架畫面與漸進式載入

骨架畫面把等待提示再推前一步：內容未到之前，先顯示灰色的版面框架，圖、標題與按鈕的位置都在。它是等待提示的一種，主要內容實際何時出現，仍要以指標量度；框架高度要接近最終內容，差得太遠，內容彈出的一刻反而突兀，還可能帶來位移。

漸進式載入則讓內容分批出場：文字先到，圖片後到；低清先現，高清補上。訪客早於完整載入開始閱讀，提前的這段時間就是體驗的增益。

畫面出現了，為何按下去沒反應？

INP 量度訪客由按下到畫面下一次回應的延遲，涵蓋輸入等待、事件處理與繪製；腳本仍佔用主執行緒時，訪客的點擊就要排隊。畫面出現與可以操作不是固定的先後兩個階段，頁面可以在資源仍下載時回應操作，也可能在載入途中反而變慢。按「加入購物車」沒反應、篩選器遲遲不出結果，先分清是回饋慢，還是仍在等功能所需的資源或請求，後者可能涉及伺服器與網絡。

改善有次序。按投訴中的步驟重現，分別試頁面仍在載入與載入後的同一操作，定位延遲在輸入等待、處理期間，還是畫面更新之前；找到之後，把長時間的處理拆細，非緊急的工作延後。界線要記住：INP 量到畫面回應為止，不是整張訂單或預約的完成，送出之後的等待要靠流程提示交代，例如「處理中，請勿離開」。

成效檢查與重測條件

改動有沒有用，要在一致條件下驗。動手前先記錄基準：同一工具、同一批頁面，手機與桌面分開記；改動後以相同條件重測。模擬報告對 LCP、CLS 與 TBT 逐項對照，總分放最後；INP 另看真實訪客資料或有互動的測試，TBT 合格不是 INP 合格的證明。模擬結果本身會波動，核對兩次報告的測試環境，別把單次升跌全歸因於改動。

真實訪客資料反映的是過去 28 日的累積，窗口包含改動前的紀錄；今天改、明天看 CrUX 未變，不代表改動無效，要配合重測判斷。自己在本機重測時，無痕視窗重現的是首次造訪；瀏覽器快取對重訪訪客是真實存在的，兩種情況分開記，登入狀態亦然。

覆核最後回到訪客行為：查詢有沒有增加、投訴有沒有減少，與速度指標一併觀察，並註明同期的廣告、內容或活動改動；前後變化不能直接推成速度的單一因果。

持續監控與日常更新

節奏不用複雜：每月為主要頁面跑一次檢測，記下三項指標的變化；上載新圖前先壓縮、按顯示尺寸輸出；外掛每季覆核一次，在用的留，不用的經測試後移除。系統或外掛更新後，重開主要頁面核對實際載入的資源版本，把修改日期、受影響網址與重測結果記進維護紀錄；訪客見到舊版本或出錯頁，是更新後值得先查的位置。

每月記錄三項指標，改動有跡可循