生活分享

Core Web Vitals 怎麼改善：從真實使用資料找瓶頸

Core Web Vitals 出現紅色項目時，先確認受影響的裝置、頁面群組與讀者操作。本文以台灣小型課程網站為例，解釋 LCP、INP、CLS 各自代表的體驗問題，整理真實使用資料與實驗室測試的分工、交給工程師的重現紀錄，以及修改後的驗收方式。附比較表與原創圖解，避免只看單次分數就大幅更動網站。

更新日期: 閱讀時間約 7 分鐘

原創螢幕、伺服器與檢查文件圖像，呈現從使用體驗找到效能原因並驗收的流程。
圖片：Mokaair (© Mokaair)

課程頁的主圖遲遲不出現、點選日期沒有反應、準備按報名時按鈕突然下移，這是三種不同的困擾。Core Web Vitals 把載入、互動與版面穩定性分開觀察，能幫助網站管理者把「網站很慢」變成比較明確的改善任務。

開始前先寫下讀者遇到的情境，以及哪一份資料指出問題。報表能指出需要關注的地方，卻不會自動告訴你是主機、圖片還是程式造成。沿著使用情境找到瓶頸，再安排修改與驗收，比一次打開所有加速選項更容易確認原因。

認識三個指標，保留它們的單位

LCP 觀察可視範圍內主要大型內容出現的時間，可能是圖片，也可能是文字。INP 觀察使用者點擊、輕觸或鍵盤操作後，到下一次畫面更新的反應情況。CLS 則衡量非預期的版面位移，不是等待秒數，也不能直接當成移動幾個像素。

截至查證日，Google 的良好門檻為 LCP 不超過 2.5 秒、INP 不超過 200 毫秒、CLS 不超過 0.1。評估通常看第 75 百分位，並區分手機與桌機；意思是至少四分之三的觀測體驗落在該值或更好，不是把所有人的結果取平均。

三個指標沒有互相抵銷的加總分數。主圖很快，不能補回按鈕嚴重卡頓；某次桌機測試良好，也不能代表手機使用者都有相同體驗。先把名稱、數值、單位、裝置和資料範圍一起抄下，才不會在溝通時混用不同結果。

先讀真實資料，再用測試找原因

Search Console 的 Core Web Vitals 報表把相似體驗的網址分組，適合觀察問題波及哪些頁面。群組中的範例網址不是完整清單，也不表示每個網址每次造訪都同樣慢。沒有足夠資料時可能不顯示，不能把空白報表解讀成全部通過。

PageSpeed Insights 的真實使用資料來自 CrUX，涵蓋過去 28 天。查看時分清是目前網址還是整個來源網站；單頁樣本不足可能改顯示來源層級資料。課程詳情頁若看到整站彙總，不能直接把問題歸給眼前這張課程主圖。

實驗室測試可在較固定的條件下重現問題，適合檢查改動。一般 Lighthouse 頁面載入測試沒有真正的使用者互動，不能直接量出 INP；TBT 可以提供阻塞線索，但兩者不是同一指標。需要互動的問題，仍要實際走過操作流程。

LCP 慢時，沿著主要內容的出現路徑查

先確認測試指出的 LCP 元素，不要預設一定是封面。課程頁在桌機可能以大圖為主，手機版則可能是標題文字。記錄畫面和元素後，才知道要檢查哪個資源，以及不同版型是否需要不同修正。

Google 的診斷方法把時間拆成伺服器初始回應、資源開始載入前的延遲、下載時間，以及下載後到呈現的延遲。若頁面 HTML 本來就晚到，只縮小圖片可能幫助有限；若圖片早已下載完卻仍未顯示，也要檢查呈現所等待的其他工作。

交給工程師的紀錄可以寫「手機課程頁主圖直到某段程式完成後才出現」，並附對應載入紀錄。這比只下指令要求換主機更具體。修正時以已確認的延遲來源為目標，再回到同樣版型與條件比較，避免把不同頁面的結果湊在一起。

INP 高時，把慢的動作重現出來

列出讀者常做的動作，例如展開課程大綱、切換日期與選擇人數，並分別在剛進頁面和載入完成後操作。部分卡頓只發生在程式還忙著啟動的時候；只等畫面完全穩定後點一下，可能錯過真正的問題。

一次互動可拆成等待事件開始處理、事件本身執行，以及後續畫面呈現。工程師可依紀錄辨認長任務、過重的事件處理或版面更新工作。下載檔案小不表示程式執行輕，快取命中也不保證按鈕能及時回應。

若按鈕點下後立即顯示處理中，但後端要較久才回傳報名結果，還需要另外記錄整個任務完成時間。INP 著重互動回應，不等於訂單完成或資料查詢總耗時。驗收既要確認畫面有即時回饋，也要確認最後結果正確。

  1. 選定受影響頁面與一個具體互動，記下裝置和登入狀態。
  2. 分別在載入期間與完成後操作，錄下可重現的步驟。
  3. 由工程師記錄效能軌跡，定位等待、處理或呈現階段。
  4. 修改後用同樣步驟複查回應與功能結果，保留前後紀錄。

CLS 高時，找出誰把內容推走

頁面位移常見於沒有預留尺寸的圖片、嵌入內容或動態插入區塊，也可能與字型載入有關。課程頁若晚出現一條通知列，把報名按鈕往下推，讀者看到移動的是按鈕，真正需要檢查的卻可能是上方通知列。

診斷工具列出的位移元素，未必就是造成位移的來源。觀察移動前後畫面，核對上方新增或變大的內容；圖片與影片可預留符合比例的空間，動態區塊則需設計合適的載入位置。不能一律用很大的空白把問題遮住，導致手機版難以閱讀。

位移也可能發生在捲動途中，或初始載入之後才加入內容。因此要從頁首讀到頁尾，操作實際會用的區塊。初次載入測試的 CLS 很低，並不足以排除整次造訪中的版面問題；可重現的畫面紀錄會比單張分數截圖更有用。

按影響範圍排優先順序，再分兩階段驗收

將問題整理為裝置、頁面群組、指標、具體情境、影響範圍、負責人與回復方式。先處理嚴重且影響重要流程的項目，再評估共用版型是否能一次改善多頁。只有少數特殊頁面發生的問題，則不必直接改動整站設定。

第一階段檢查修改是否部署到預定環境、重現步驟是否改善，以及表單、選單和報名流程是否仍正常。第二階段追蹤真實使用資料；由於報表包含過去 28 天，當天修正不代表歷史資料立即消失，應在紀錄上標示變更日期。

Search Console 的開始追蹤會啟動一段監測流程，不會因此重新索引網站。持續觀察範圍與數值，同時留意流量來源和裝置組成是否改變。完成定義應是問題已修正且有可核對的驗收依據，不能只寫「已安裝加速外掛」。

四個區塊依序呈現資料範圍、問題重現、針對原因修正，以及即時功能與後續真實資料驗收。
每一筆效能問題，都要對應讀者情境與可複查的結果。 · 圖片：Mokaair (© Mokaair)
以查證日的官方門檻為準，應核對第 75 百分位與裝置、網址範圍。
指標良好門檻先定位的問題
LCP≤ 2.5 秒主要內容在哪一段等待
INP≤ 200 毫秒哪個互動回應緩慢
CLS≤ 0.1，無單位誰使可見內容意外移動

同主題延伸閱讀

  • 生活分享

    Wix 架站指南：編輯網站、選擇方案與網址

    第一次使用 Wix，先釐清網站要完成什麼，再選擇版型與付費方案。本文以原創修鞋工作室介紹站為例，整理 Wix Editor 的頁面編輯、手機檢查、儲存預覽與發布流程，並說明自訂網域、續費、台灣付款工具及平台搬遷限制。附操作步驟、比較表和自繪圖解，協助把網站內容、功能需求與長期管理成本一起考慮，避免只看首頁完成就急著升級。

  • 生活分享

    線框圖與原型怎麼用：先驗證流程再修視覺

    線框圖、視覺稿與互動原型各有用途，重點是目前需要驗證哪一個問題。本文用原創到府植栽照護預約情境，說明如何挑選保真度、補齊流程與例外狀態，準備不暗示答案的操作任務，再將測試觀察轉成修改紀錄。附操作步驟、比較表及原創圖解，協助設計初學者與小型團隊，在投入正式開發前先看懂使用上的困難。

  • 生活分享

    www、子網域與子目錄：網站網址結構怎麼決定

    網站要不要加 www，部落格該放 blog.example.com 還是 example.com/blog/，需要從平台支援與維護方式一起判斷。本文先拆解網址中的主機名稱和路徑，再比較子網域與子目錄的內容分工、DNS 設定、HTTPS 憑證及網址一致性。附上原創決策表與上線檢查步驟，協助台灣小型網站建立容易使用、管理和交接的網址結構。

  • 生活分享

    網站維護要做什麼：備份、更新與故障回報的日常安排

    網站維護不只是更新外掛，也包含確認內容、帳號、備份、寄信與到期服務。本文以小型 WordPress 內容網站為例，把維護工作拆成日常觀察、更新前後檢查、備份還原及故障回報，提供可以分配給站主、編輯與維護者的工作表。你可以依網站更新頻率安排合適節奏，知道什麼情況要立即處理，並保留足以讓下一位協作者接手的紀錄。

引用本文的文章

最新旅遊情報攻略

資料來源

生活分享