首屏載入慢？先診斷最大內容繪製，才決定如何改圖

先選顧客真正會開啟的頁面

先選定一段顧客旅程：有人從訊息進入產品頁，看見貨品資料，再決定是否繼續。最大內容繪製（LCP）記錄畫面中最大圖片或文字區塊何時顯示，反映頁面載入，不是付款授權或稍後按鈕回應所花的時間。請記下實際網址、手機或桌面畫面、登入狀態，以及入口會否先轉址。這些條件決定你量度的是哪一次載入。若把首頁、產品詳情頁和已快取的內部測試混成一個平均數，團隊便無法判斷應改哪一環。

Google 指引以至少四分之三的頁面瀏覽在二點五秒或以下完成 LCP，作為良好體驗目標；這是公開基準，不是本店的實測成績。辦公室一次快速測試不能代表大部分顧客，一次慢速錄影亦不能證明全站有問題。若 PageSpeed Insights 提供該網址和裝置類別的真實用戶資料，先看相符的一組；若只顯示整個網域資料，必須標明，因為同一網域不同頁面的載入方式可以很不同。流量少的頁面可能沒有公開頁面資料，可審慎收集相關頁面的真實時間資料，或以實驗室記錄分析可能原因，同時清楚區分兩種證據。

確認實際最大的畫面內容

在選定網址和合理的畫面尺寸錄製載入記錄，先找出實際的 LCP 元素，不要預設必定是產品相片。最大內容可能是標題、主圖或另一段可見文字；畫面尺寸不同，結果也可能不同。記下元素，以及所需資源的網址，再比較主文件和該資源開始、完成下載及最後顯示的時間。單看截圖不足以判斷，因為截圖看不見請求先後。如果 LCP 是標題，縮小產品圖或許能節省流量，卻未必改善指標；如果 LCP 是產品圖，先改頁尾程式亦可能沒有作用。

把 LCP 分成首個 HTML 位元組到達前的時間、資源開始下載前的等候、資源下載時間，以及資源已到達但元素尚未顯示的等候。四部分合起來就是該次載入的 LCP；若最大元素是毋須額外下載資源的文字，相關下載部分可以是零。請從工具讀取實際數值，不要憑印象分配百分比。這個拆分有助決策：先處理主要而可避免的等候，再確認整體 LCP 是否改善，不應只追求其中一段時間看起來較短。

按延誤來源選擇改動

若主要時間花在取得首個 HTML 位元組，先檢查轉址、伺服器回應和到達頁面的路徑，毋須立刻改圖。即使最終圖片很小，多餘轉址或緩慢的主文件仍會拖慢首屏。若主要問題是資源太遲才開始下載，便查明瀏覽器為何未及早發現：圖片可能藏在 JavaScript 後、以 CSS 背景形式遲出現，或可見主圖被設定為延遲載入。可行時讓重要資源在初始 HTML 便可發現。若主圖確實是 LCP 元素，應先看網絡時序才設定優先級；把多個資源一律設成高優先級，便失去區分重點的意義。仍須保留顧客購買所需資訊。

若資源下載本身最慢，再檢查傳輸大小、尺寸、格式和交付方式，但產品圖片仍須保留讓顧客判斷所需的細節。這才是調整響應式圖片的適當位置，而且要針對實際 LCP 元素。若下載完成後仍遲遲不顯示，圖片可能被程式、樣式表、字體或隱藏容器擋住。Google 特別指出：壓縮圖片雖可縮短下載，節省的時間卻可能轉移到顯示延誤，總 LCP 完全不變。此時應找出阻礙顯示的依賴；文字是 LCP 時，字體和樣式表往往比圖片更值得查。每項改動都要說明觀察到的瓶頸和預期整體效果。

以一個假設例子排優次

以下是假設商店頁面，並非客戶實測。手機載入記錄顯示主產品相片是 LCP 元素。HTML 已到達，但瀏覽器要等程式執行才知道圖片網址；圖片下載其實不算慢，之後又因頁面轉場而要待另一段程式完成才顯示。首項改動不應自動選擇更激進地壓縮圖片。先讓圖片網址可在初始標記中找到，移除首屏主圖不適當的延遲載入，再檢查轉場為何阻礙顯示。每次只改一小處，重新記錄請求起點、圖片完成時間和最終 LCP。若總時間沒有改善，下一個假設便是顯示延誤；只把時間在不同部分之間搬移的改動，值得考慮撤回。

再假設第二次記錄中，最大元素其實是產品標題而非相片。改圖或可節省數據用量，仍有其他價值，卻已不再是針對 LCP 的處方。這時應查標題何時進入文件、樣式表會否阻礙首次顯示，以及網頁字體會否拖慢可閱讀文字。團隊因此要與結果一併保存元素身分。版面、語言、推廣橫幅或畫面尺寸改動，都可能換掉最大元素；中英文頁若文字長度或模板不同，便要各自檢查，不可把一種語言的測量當作兩者共同結果。

若首屏有輪播推廣圖，還有一個特別情況：投影片出現先後可改變最大元素，把每張都設高優先級，反而可能擠掉第一張所需資源。應先確認顧客初進頁面真正看到甚麼，再看後續投影片是否過早下載，並問輪播是否真的幫助購買判斷。較簡單的固定首屏可能更易理解及量度，但也要先檢查內容需要，不能只為分數而刪掉有用資訊。推廣團隊更換首張圖片後，須重新錄製載入時序；舊的 LCP 元素和資源優先級假設可能已不成立。這同時是內容與載入設計的決策，不只是開發設定。

改動後核對顧客體驗

前後比較時，實驗室測試須使用同一網址、畫面尺寸、網絡假設和瀏覽狀態，並重複多次，因為單次記錄會波動。若流量足夠，再持續觀察相應真實用戶資料，分清頁面與整個網域、手機與桌面。一次本地改善只代表值得繼續觀察，不能宣布所有顧客已達標。同時檢視畫面：產品名稱、價格、存貨資訊和購買路徑在載入時仍要清楚。把有用資訊藏起來，或把有意義的相片換成空白框，即使數字變快，也不是較好的顧客體驗。

給負責人留一份簡短決策紀錄：測試頁面和裝置、證據來源、LCP 元素、四段時間、已作改動，以及改善了甚麼和仍未知甚麼。日後發版便能辨認退步原因，不用猜當初為何修改。沒有真實用戶資料，就如實註明，不能把沒有測量當作零。若實驗室與真實資料不一致，先查訪客裝置、快取狀態和網絡條件，再決定是否改下一處。當主要訪客有可辯護的結果，而且購買流程仍然順暢，便可按證據評估下一個頁面，而非把同一處方套到全站。

還要指定一位負責人決定改動可否上線。開發者可提供載入記錄和時序解釋，但產品負責人亦應用普通手機查看，確認首屏能回答顧客最急切的問題。產品頁通常要看得到貨品名稱、有意思的相片、價格，以及進一步了解的路徑。若把圖片設為高優先級，反而與必要文字或程式爭用資源，負責人可要求另一個設計，不必只接受單一指標。紀錄實際測試的裝置和語言；桌面截圖不能證明手機首屏的體驗。這是有證據支持的發布決定，並非宣稱已取得普遍適用的分數。 若顧客主要從社交平台的內置瀏覽器進站，也應另取實際樣本檢視；其快取及連線情況未必與辦公室的桌面瀏覽器相同。把入口差異記入紀錄，有助日後知道為何同一網址會有不同結果。