Core Web Vitals改善：分清載入、互動與版面跳動問題

Core Web Vitals改善：分數漂亮但客人仍嫌慢，先看哪份報告

Core Web Vitals改善不是把測試工具的分數推高便完成。假設某公司在辦公室用高速網絡測得首頁表現良好，客人用手機打開產品頁卻等了很久才能看到重點，按表單時還要等待回應。這兩種觀察未必矛盾：測試頁面、裝置、網絡、數據來源與量度項目不同。先查是哪一頁、哪項任務出了問題，再安排具體修改。

Google 將核心網頁指標用於描述真實使用體驗的載入、互動及視覺穩定程度；目前常談的是 LCP、INP、CLS。這裏不以分數承諾搜尋排名，而是將指標當成排查線索：網站為甚麼未見主體內容、為甚麼按了沒反應、為甚麼文字突然移位。若不了解各指標描述甚麼，投入大量時間改錯地方，反而會令真正的客人問題留在原地。

第一張報告：真實使用者資料與現場測試要分開讀

欄位代表的是哪個頁面與哪類訪客

檢查 Google Search Console 或相關量度工具時，先確認報告是以整個網站、某組相似網址還是單一測試頁作判斷。有的頁面資料不足，可能借同類網址或整個來源的資料作參考；不能把一張首頁報告直接當成所有商品頁都正常。要記下資料的期間、裝置類別和網址，再挑出業務最重要的頁面核對。公司網站 SEO 基礎所說的重要頁面盤點，可幫助決定先看哪些入口。

實驗室檢測適合找原因，不能取代真實體驗

現場測試可控制裝置與條件，找出渲染阻塞、圖片尺寸或長時間運行的程式；真實訪客可能用不同手機、訊號和瀏覽器。某次測試表現好，不代表訪客在繁忙時間或產品圖片較多的頁面同樣順暢。先問「這份資料回答哪個問題」，再把工具建議轉成可重現的測試步驟，不要把幾個不同來源的分數直接加總。

• 記錄原始網址、測試日期、裝置及測試條件。
• 分清真實使用者資料與一次性的診斷數值。
• 確認改動前後看的是同一種頁型和任務。
• 無足夠真實資料時，清楚標記暫時只能作推測。

LCP：最大主要內容為何遲遲未出現

先找被量度的元素，不要先猜圖片一定是元兇

LCP 指頁面在可見範圍內的最大內容元素呈現時間，元素可是一張圖片或大段文字。檢查工具顯示哪個元素、資源請求何時開始、前端是否因樣式和程式而遲遲不能顯示。若只是把圖片壓小，卻沒有處理伺服器回應、錯誤的資源載入次序或延後渲染，改善可能有限。頁面樣式及內容會影響被選作量度的元素，所以不同頁面可能需要不同處理。

把等待時間分段，工作才不會全推給寄存

從伺服器開始回應，到瀏覽器發現圖片、下載資源、完成繪製，各段都可能耗時。先查看 HTML 是否包含所需的首屏內容、最重要圖片是否被過度延後、字型與樣式是否拖住顯示。若資料庫查詢令回應很慢，可在網頁寄存與伺服器配置一併檢查環境；若回應夠快但前端仍遲顯示，便應檢查頁面設計及程式載入。遇到第三方資源，也需區分哪段由網站可控制。

INP：按鈕已按，畫面幾時才給反應

區分輸入延遲、處理工作與顯示下一畫面

INP 關注使用者互動至下一次畫面繪製之間的反應，不能只看網頁剛載入。假設客人按「加入購物籃」，瀏覽器當時正在處理一段長程式、事件本身又花時間，或後續版面重繪繁重，便可能覺得按了沒有反應。要重現具體動作：點哪個按鈕、頁面有幾多商品、何時輸入資料，然後看主要執行緒的工作，而不是一律要求「伺服器加快」。

不要用假的即時反饋掩蓋未完成工作

如果提交表單需要等待伺服器回覆，介面可以告訴客人正在處理並避免重複按，但不能先顯示「已成功」再讓後台無聲失敗。改善前端反應時，同時測試網絡較慢、使用者按兩次、輸入有錯誤的情況。需要大量運算時可拆開不必要的同步任務，讓瀏覽器有機會更新畫面；每一步仍要核對最終結果與訂單資料一致。

CLS：頁面為何突然跳到另一個位置

先查未預留空間的元素

圖片、廣告區塊、通知列、嵌入內容如果在頁面顯示後才插進來而未預留位置，文字與按鈕可能被推走。客人本來準備按「提交」，按鈕卻因上方元素出現而移位，是具體可感的風險。給可預知尺寸的媒體留空間，檢查動態內容顯示的時機與位置，再重測實際操作。不要為了追求數字，在首屏故意留下大片沒有內容的空白。

字型、錯誤訊息與後台插入區也要看

字型更換可能改變字行寬度，表單顯示錯誤訊息也可能把下一個欄位推落去。CLS 排查要看真實畫面從頭到尾的變化，不只看截圖。若只有商品缺貨時顯示警告造成跳動，便需建立對應測試資料；若所有頁面共用同一個通知列，可考慮先處理共用版型。處理結果應以錄屏與量度一同驗證。

把三項指標與公司要完成的事接上

服務頁與文章頁有不同的主要內容

文章頁通常要讓讀者早點看到標題與正文；服務頁可能包含大幅主圖與查詢入口。量度順序要按用途排，不能只因首頁最漂亮就先處理首頁。假設訪客從搜尋直接進某篇教學，該文章大量圖片拖慢主體內容，應先處理它而不是修改無關的關於我們頁。網上推廣帶進來的著陸頁，也要測試廣告所說內容是否及早可見及能完成查詢。

手機版可用與效能是相連但不同的問題

慢的網站令人等，排版錯的網站令人找不到下一步。檢查手機版選單、表格與表單操作時可同步量度效能，但不要用 Core Web Vitals 三項數字代替完整的易用度驗收。手機選單即使反應極快，若文字讓人看不懂仍需重寫；反之選單設計清楚，若點擊後長時間卡住也要追查程式。

• 為每種頁型記錄最重要的使用任務。
• 對應三項指標找主要等待或移位的位置。
• 按業務影響、可重現程度與改動風險排序。
• 修正後重跑同一任務並觀察真實資料趨勢。

改版期間不要一次更動太多變量

建立改動紀錄，方便排除「變快還是變慢」

改圖片、換版型、加分析工具、搬寄存同時發生，之後無法知道哪個環節令量度變化。將要處理的網址、資源、修正方案、負責人和回退條件寫進變更表；若配合網站改版 SEO 對照，需同時檢查內容和網址是否保持正確。效能改善不值得以重要正文消失或導覽失效作交換。

先測安全的樣本，再擴到相似頁型

若全部產品頁用同一模板，可選一個圖片較多、資料較複雜的樣本先修改。測試桌面與手機、首次與再次載入，以及登入與未登入狀態；確認功能及版面無誤，才部署到整個模板。改動後監察錯誤與顧客反映，若某些裝置出現新問題便按回退方案處理。單次測試變好可視作線索，真實資料仍要經過一定時間累積才能看趨勢。

先確認量度環境沒有把自己騙倒

登入者看到的畫面可能與訪客不同

公司編輯員登入後可能看見工具列、預覽按鈕和未公開內容，客人未登入時則看到快取過的正式頁。測試兩種身分可以找到個別問題，但核心業務頁的量度應用真實訪客路徑重現。網站若按語言、位置或登入狀態顯示不同內容，先記下測試畫面實際包含甚麼，再比較結果。不要拿簡化的測試頁分數去承諾真實商品頁會有相同表現。

測試前先清楚寫裝置與網絡條件。手機模擬可幫助定位某些問題，卻仍須用真實裝置檢查鍵盤、觸控和載入順序。若同事一位用辦公室 Wi-Fi，另一位用流動網絡，結果不同屬正常線索，不必強迫兩人的數字完全一樣；應問哪個條件接近主要顧客的使用情況，並把其他情況保留作風險檢查。

分數出現變化時先看內容有沒有改

一個星期內上載了大量商品相片、加入廣告追蹤程式或更新頁面版型，量度自然可能跟着變。先核對改動日期、受影響的頁型與資源，再看網站前後兩段時間的資料；若每天訪客量和裝置比例亦不同，單純對比兩個總數便可能誤判。工具給出建議只是排查起點，實際更動應有負責人檢查對業務功能的影響。

還要看量度有沒有「看不見」的部分。某些互動太少的頁面可能缺少足夠 INP 資料；新上線頁面也可能尚未有穩定的真實使用資料。這不表示互動肯定良好，更不能據此宣稱已通過所有指標。安排受控的人工任務測試，將「目前沒有足夠資料」與「已觀察到不良表現」分開記錄。

LCP 排查可按資源的生命週期逐步問

重要圖片何時才被瀏覽器發現

若主視覺圖片在初始 HTML 已有明確資源，瀏覽器通常可以較早開始處理；若靠後來的程式動態插入，開始請求的時間可能延後。檢查原始文件與網絡資源時間線，找出瀏覽器是何時知道要載入它。對首屏很重要的圖片，不宜不經判斷就套用為了節省頁面下面資源而設的延後載入方式。另一個要看的是尺寸：同一張大圖片若在手機只顯示小幅版面，需考慮提供適當尺寸，但別因此刪掉顧客閱讀商品需要的細節。

有些頁面 LCP 元素其實是大標題文字，延遲原因可能是字型、樣式或整段內容由前端程式載入。此時只更換圖片格式幫助有限。把元素種類寫在問題單上，標明屬哪個模板，設計與開發同事才能選對方法。改動後也要重新量度所選元素，因為主體內容的配置變了，工具可能選另一元素作新的 LCP。

伺服器回應慢時看哪些證據

請技術人員按實際請求查記錄，分辨是資料庫查詢、應用程式計算、外部接口等待，還是寄存環境資源被擠滿。網店商品頁可能因不同變體要即時計價；靜態公司資訊頁則可能容易用合適快取方式改善。不能為了讓回應快，錯誤快取登入者資料、個人價格或購物車內容。先寫明哪些資料可共用、哪些必須逐個使用者計算，再決定快取及擴容策略。

若計劃使用內容傳遞網絡，亦要明白它通常較適合分發可快取的資源；結帳、登入與即時查詢的速度，還受程式和資料來源影響。量度時分開首個回應時間與整體顯示時間，避免把所有等待都算在同一個供應商身上。改善工作應指出哪一段最長，選擇能對應那段的措施。

INP 的診斷要走過真正的使用行為

選單、篩選器與表單逐項點

訪客可能先打開手機選單，再用商品篩選器，最後才提交表單；每次互動都可能執行不同程式。讓測試者依固定路徑操作，錄下在哪次點擊後畫面遲遲未更新，以及當時頁面是否正在載入其他資源。先別一看到慢就把所有 JavaScript 一律刪掉；應辨認哪一段工作擋住瀏覽器處理輸入，移除不必要的計算或分拆繁重的工作。

表單即時驗證很方便，但每輸入一個字都重新計算大量規則或重畫整頁，便可能拖慢回應。可以檢查是否有重複事件監聽、過多畫面更新或第三方程式在同一時間爭奪執行時間。改善後用含錯誤資料、正常資料與快速連續操作三種情境重測，確保在增加反應速度之餘，資料驗證沒有被刪掉。

操作成功與否要比按鈕動畫更重要

按鈕立即轉色可以讓人知道已按下，卻不能代替真正的提交結果。測試時故意模擬伺服器無回應、表單資料不完整或用戶重複點擊，核對畫面是否說明正在處理、怎樣修正以及是否已成功提交。若錯誤訊息無法被使用者看見，主觀體驗仍然差。效能與可用性必須一起驗收，否則只是把等待藏起來。

不少互動在頁面剛開時感覺較慢，因為背景還在執行初始化工作。檢查能否把非必要程式延後至合適時機，或縮小首屏必須運行的工作量；但第三方追蹤若涉及營運量度，也要與負責人確認，不能單由開發者刪除。把「保留、移除、延後」決定和原因記錄下來，日後廣告或統計設定改動才不會反覆造成同一問題。

CLS 改善必須靠看得到的畫面驗收

圖片、橫額和通知列逐個重播

用錄影回看頁面從空白到完成的過程，注意商品圖片下方的文字有沒有被推開，頂部促銷列是否後加，手機上彈出的提示會否遮住正在填的欄位。規劃固定或可預期的空間，可降低某些意外位移；但如果通知內容長短不一，仍要測試較長版本。對完全無法預知的內容，考慮將提示放在較不會推移已讀內容的位置，同時保留可讀性和關閉操作。

表單在報錯後新增提示屬使用者觸發的畫面改變，不應一律當成與載入時無關的佈局跳動；實際仍要觀察客人是否因此看不到原先欄位，或錯誤提示沒有靠近出錯項目。每次修正 CLS 時保持介面有足夠資訊，避免為了數字好看而完全不展示必要的錯誤。

字型載入後的跳動也要實際查

有些中文字型在載入前後字距不同，長標題會改行，下面整段內容便一起移位。檢查字型的載入安排、替代字型的版面差異以及首屏是否真的需要額外字型。若設計希望維持品牌風格，可用受控測試比較清晰度和穩定程度；不必把所有文字都換成同一種字型才能改善。若只有個別長標題出現問題，亦可先改善版型容錯。

不同語言版的標題長度可能很不同。中文版只有一行，英文版變成三行，若空間被寫死就容易遮住其他元素。用典型長標題、含按鈕的通知及缺貨提示重測，建立版型在真實內容下的行為，而不只使用設計稿上的短字樣。

交付前留一份「修了甚麼、仍未解決甚麼」

一次效能工作通常不可能同時覆蓋全部頁面和全部裝置。交付記錄要列出測過的網址和操作、前後的量度條件、修正的資源與程式、仍需觀察的頁型，以及萬一功能異常如何回退。若改動只對一類商品頁有效，不要概括說全站速度已改善。這樣既能避免不實承諾，也讓後續負責人知道哪些工作可以沿用、哪些假設需要再驗證。

若商戶原本沒有完整量度資料，先建立可重複的樣本測試；隨使用資料累積，再回頭檢查真實趨勢是否與測試相符。碰到外部廣告、付款或分析工具，先與業務負責人釐清重要性，再決定是否調整載入方式。效能數據應幫公司安排下一步工作，而不是變成一個為爭取漂亮分數而犧牲功能的目標。

將排查變成具體工作分派

設計師處理甚麼

若頁面因橫額、字型和圖片比例而出現 CLS，設計師可先確認每個位置本應承載甚麼內容，以及長標題和錯誤訊息應怎樣容納。若將頁面重要圖片縮到很小雖然提升載入分數，卻讓商品細節不能閱讀，就要重新在清晰度與資源大小之間找平衡。交付給開發人員的設計稿，應包含圖片尺寸、載入前後狀態及小螢幕的變化，而不是只給一張完成後的截圖。

開發與寄存團隊處理甚麼

開發人員可按效能時間線找阻塞渲染的程式、導致互動遲緩的長任務與重複事件；寄存團隊則按真實請求核對資源使用和伺服器回應。如果根源是未索引的資料庫查詢，單換速度較快的圖片未必奏效；如果根源是外部追蹤碼在瀏覽器執行太久，單加伺服器資源也無法直接縮短。記錄哪一組已接受任務，避免網站有事時互相推責。

內容與行銷同事怎樣參與

內容同事應提供最有價值的頁面和讀者常用入口，辨認是否有過大而非必要的圖片、重複橫幅及折疊得難以閱讀的正文。行銷同事要列出每個第三方追蹤程式的用途、是否仍在使用、延後載入會否影響量度，讓技術人員知道能改甚麼。倘若某個工具已停止投放卻仍在每頁載入，就可先由業務確認移除，再觀察實際變化。

表現沒有即時變好時怎樣避免錯誤結論

區分部署結果和真實資料累積

修改部署後，受控測試可能立刻看見結果，真實使用者報告則需有訪客累積，未必即時刷新。檢查部署是否真的到達正式頁、快取是否仍服務舊資源、測試路徑是否相同，才討論真實數據有沒有改善。若同時換了商品照片或加入新工具，先記錄變更並重新測試，不能只憑舊報告說修正完全沒有效。

頁面使用量如果很少，真實資料不足時可先用可重複的現場測試、程式分析與人工操作作驗收，清楚標記待累積資料再覆核。這比隨意取一個「效能滿分」截圖作結案更誠實。商戶亦應知道哪項改善屬直接可見，例如按鈕回應較快，哪項仍須觀察較長時間，例如不同手機訪客的載入情況。

不要單為量度而刪除重要內容

若首屏改得只剩幾個字，LCP 可能看起來較好，但客人進站後反而找不到產品用途與交付條件。SEO 所需的有用內容、清楚的導覽與可達成的行動要和效能一起衡量。選擇一項修改時先寫出功能不可以失去甚麼，再量度速度與使用者完成任務的結果；如果一項技術改善造成查詢表單不穩定，應先修復功能或回退，而不是保留漂亮數字。

不同頁型可採不同設計與快取策略，沒有必要把所有頁面變成同一張簡化模板。服務頁應清晰交代服務，網店頁要支援選購，教學文章則要易讀。讓效能團隊看到業務需求，才能把指標用作線索而非唯一裁判。

驗收時可以由一名平時不參與技術會議的員工，按指定手機和網絡條件完成任務，再說出他看見何時開始等待、何時按鈕可用、是否有內容突然移動。技術人員將其觀察對到工具時間線，才知道報告建議是否對應真實痛點。如果工具顯示改善而員工仍在原位置卡住，便重查測試的網址、使用情境和第三方資源。

還要確認舊裝置的基本功能：某項修改若只在新瀏覽器表現良好，應記下網站實際支持的裝置範圍，找出客戶常用裝置會否受影響。按重要程度修正或回退，並把不能覆蓋的情況寫入交付。效能工作不等於只為測試機器服務；最終仍要讓真實客人順利讀內容、查資料和提交查詢。

如果同一頁在桌面順暢、手機卻遲緩，先看裝置、網絡和互動程式的差異，再決定修正範圍。交付資料要保留具體例子與測試條件，方便日後加入新功能時重新核對，而不是只留下「已完成優化」的抽象說法。

交付一張能分派工作的效能問題單

Core Web Vitals改善的出發點是客人完成任務所遇的阻礙。把頁面、裝置、當時行為、觀察到的 LCP、INP 或 CLS 問題，以及可重現步驟交給合適同事：後端查詢、寄存回應、前端資源或互動程式，各有不同責任。需要評估網頁設計及程式修改時，可透過聯絡 Black Media並附上有關網址與測試紀錄，先確定問題所在再安排工作。