落地頁速度怎麼量?LCP、實際訪客與轉換測試

MeetROAS 編輯團隊 · 發布 · 更新

量測落地頁速度,要先固定廣告實際目的地、裝置與方法,再看主要內容及下一步能否完成。實驗室適合排查,真實訪客資料用來觀察分群經驗;LCP、載入完成與轉換不是同一件事。缺資料不等於零,速度改善也不直接證明業務成效。

落地頁速度,要分清「哪一頁、哪群人、哪個時間點」

量測落地頁速度,應先固定實際廣告目的地、裝置與量測方式,再看主要內容何時出現,以及訪客能否完成下一步。 PageSpeed Insights 的實驗室分數、真實訪客的 LCP 與註冊率回答不同問題,不能互相代替。LCP 是 Largest Contentful Paint,指可視區域中最大合格圖片、文字區塊等主要內容的繪製時間。

例如投手看到一次測試得 98 分,實際用手機點廣告卻等很久才看到主圖。先不要判定報表壞了:測試條件、跳轉路徑及訪客裝置可能不同。也不能只因轉換率偏低,就斷言載入慢是原因。

實驗室用來找原因,真實資料用來看訪客經驗

PageSpeed Insights 說明區分兩種資料。實驗室是受控環境中的模擬載入,適合重現問題;真實資料來自符合條件的 Chrome 使用經驗,反映不同裝置及網路。兩者數值不同,不代表其中一個必然錯誤。

讀報告時先確認四個標籤:手機或桌面、單一網址或整個來源網站、實驗室或真實資料、收集日期。來源網站(origin)通常以協定、主機與連接埠界定;它的整體資料不能當成某個 Campaign 頁面的專屬結果。

PSI 真實資料涵蓋過去 28 天。單頁樣本不足時,可能改顯示來源網站資料;來源網站也不足,就沒有可用的真實資料。這不是「速度零秒」,也不是已通過。依 CrUX 方法說明,公開可發現性與足夠樣本都是納入條件;缺資料不能單獨診斷為流量少或索引故障。

LCP、首次內容與載入完成不是同一件事

以下全是虛構教學時間,非 MeetROAS 或客戶實測。假設一次固定條件的實驗室載入,首次內容繪製 FCP 為 0.9 秒、主要圖片成為 LCP 的時間為 2.8 秒,之後在 4.0 秒觸發 load。順序只是本例,不代表每頁都相同。

假設單次實驗室載入:FCP0.9秒、LCP2.8秒、load4.0秒;主內容出現不等於成交,載入完成不保證可操作。
虛構教學時間,非產品或客戶實測。橫軸為秒,0至4秒等比例;順序只是本例。實驗室不代替真實訪客,LCP不代表成交,load不保證功能可用。

FCP 表示開始看見內容,可能只是文字;LCP 關注較大的主要內容。依 LCP 官方定義,真實量測還可能包含連線、跳轉及伺服器等待,因此只看圖片下載時間並不完整。

MDN 的 load 說明則是頁面及相關資源載入後的事件,延遲載入資源除外。它不保證表單、安裝提示或付款流程已能正確操作。投手仍要在實際手機上走到真正完成;看到主圖、按鈕有反應及註冊成功,應分開檢查。

用具體數字理解 p75,而不是只看平均

官方建議把手機、桌面分開,以載入的第 75 百分位(p75)評估 LCP,良好目標為 2.5 秒或以下。LCP 良好不代表整體 Core Web Vitals 都通過,還有互動與版面穩定等其他面向。

再看一組假設:同一頁、同一版本、同一觀察期間的十次手機造訪,LCP 由小到大為 1.0、1.1、1.3、1.5、1.8、2.0、2.3、2.8、3.6、4.2 秒。僅為教學,採「向上取整排名」算法:十筆乘 75% 為 7.5,取第八筆,得到 2.8 秒;平均則為 21.6 ÷ 10 = 2.16 秒。

教學摘要秒數
平均2.16
p75(本例算法)2.8
最慢一次4.2

平均較低,仍掩蓋了一部分等待較久的造訪。這十筆只是說明算法,不是 CrUX 計算實作、足夠的正式樣本或站點達標證據。也不要將桌面的快數字混入手機,稀釋原本要處理的人群問題。

投手可以照這個順序量測

  • 保存真實路徑。 記錄廣告目的地、必要跳轉、最終頁面與版本;用測試流程確認,不把內部測試當成付費成效。分享測試網址前移除私人識別值。
  • 先分群。 手機與桌面分開,另記地區、網路及首次或重複造訪。不要拿不同人群、不同期間的結果直接宣布進步。
  • 固定條件重跑。 在相同工具、裝置與網路設定下重跑數次,保留每次數字與時間;例如事先固定五次,記錄中位數及範圍。這是自己的排查規則,不是 Google 達標門檻。
  • 把觀測交給開發者。 保存主要內容何時出現、失敗資源及相關截圖,請工程師區分跳轉、伺服器等待、圖片或前端處理;不能從一個總分指定根因。
  • 檢查完整下一步。 測試按鈕、表單與錯誤恢復,並用漏斗定位真正停住的階段。也核對廣告與頁面的承諾,避免把訊息不符全算成速度問題。

沒有真實資料時,可先做受控測試及實際裝置排查,再規劃合適的真實使用者量測;不要捏造不存在的訪客百分位。改善上線後,28 天混合窗口不會立即變成純新版結果,應保存版本日期並分清比較範圍。

速度變快,仍要量真正成果

以下也只是規劃假設。兩個內容與方案相同的頁面,B 壓縮主圖;A、B 各有 1,000 位符合條件的不同到站者,每人最多計一次有效註冊,採相同七天觀察長度,並排除測試帳號。假設 A 有 80 次、B 有 90 次有效註冊,率分別為 8% 與 9%。

多一個百分點不直接證明壓圖造成提升。測試前應指定主要成果、有效分配、樣本及停止規則,控制其他重要改動;沒有可靠隨機分配時,明列客群與時間差異。可依落地頁A/B測試案例規劃分配及解讀比較。再確認後續結果及成本,不能把表單點擊換算成註冊或利潤。

MeetROAS 可協助對照 Campaign 頁面與已接入的下游結果;事件文件區分完成註冊與有效入金。這些成果可配合速度實測觀察,但不會代替 PSI/真實使用者量測,也不表示內建相同的 LCP 或 CrUX 報表。

速度有助於體驗,但不能保證轉換提升或搜尋名次。Google 的頁面體驗說明也提醒,工具中取得好成績不保證排到最前面。先量對問題,再用成熟的業務成果決定下一步。

資料來源