Landing Page 速度指南：廣告漏斗、CWV 與 15 項驗收
直接答案：Landing Page 速度慢會在廣告 Click 之後造成多種不同損失：頁面未完成載入就離開、主要內容太遲出現、CTA 按了無反應、版面移動導致誤按、Google tag 未及執行，或手機低速網絡下根本無法完成表單。不要只看 PageSpeed 100 分，也不要把轉換下降全部歸因於速度；應把「廣告 Click → 成功到站 → 主要內容可見 → CTA 可操作 → 有效查詢 → CRM 結果」逐層對數，再按真實使用者數據、裝置、頁面模板及流量來源修復。
Landing Page 速度如何影響廣告成效？
| 層級 | 速度問題 | 可能觀察 | 不能直接下的結論 |
|---|---|---|---|
| 廣告到站 | Redirect、DNS、TLS、Server 或頁面失敗 | Click 有、GA4 Session 少 | 差額全部是速度造成 |
| 理解 | Hero／主標題／價格太遲出現 | LCP 差、早段離開 | LCP 是唯一離開原因 |
| 操作 | JavaScript 長任務、主線程阻塞 | 按鈕、Menu、表單延遲 | Lab TBT 等同真實 INP |
| 穩定 | 圖片、banner、字體、表單後載入移位 | CLS 差、誤按、閱讀被打斷 | CLS 改善必然提高轉換 |
| 量度 | Tag 太遲、Consent、Redirect 或參數遺失 | Click／Session／event 對不上 | 沒有 GA4 就代表沒有訪客 |
| 業務 | 載入慢與訊息、Offer、CTA 問題並存 | 查詢少或質素差 | 加 CDN 就能解決整個漏斗 |
完整 Landing Page 結構可先看Landing Page 是甚麼及發布清單；本篇只負責速度、廣告到站、可操作性及量度邊界。
先分清五種「快」：伺服器、顯示、互動、穩定與任務完成
- 伺服器回應：Redirect、DNS、連線、TLS 及 Time to First Byte 是否拖延第一份 HTML。
- 主要內容可見：Hero 圖、H1、Offer 或關鍵文字何時真正畫在首屏。
- 可互動：使用者按 CTA、Menu、Selector 或表單時，頁面多久有下一個視覺回應。
- 版面穩定：圖片、字體、Cookie banner、Chat widget 或驗證訊息有沒有令內容突然移位。
- 任務完成：使用者能否理解、比較、填寫、提交並收到成功狀態；這不是單一速度分數。
只優化其中一層可能沒有商業效果。例如伺服器很快，但 1 MB Hero 圖被 lazy-load；LCP 可能仍差。Lighthouse 分數變綠，但真實手機使用者仍被第三方聊天及 A/B Test script 阻塞；Field INP 仍可能差。
Core Web Vitals 應該怎樣判讀？
| 指標 | 代表甚麼 | Google 建議「Good」 | Landing Page 常見根因 |
|---|---|---|---|
| LCP | 首屏最大圖片或文字何時顯示 | ≤ 2.5 秒 | TTFB、Hero 圖、字體、render-blocking CSS、錯誤 lazy-load |
| INP | 整次訪問互動回應表現 | ≤ 200 ms | 大量 JavaScript、tag、widget、長任務、複雜 DOM |
| CLS | 頁面非預期移位 | ≤ 0.1 | 圖片無尺寸、動態 banner、字體、嵌入、錯誤訊息 |
門檻要在手機與桌面分開，以第 75 百分位判斷。這代表至少 75% 的實際載入符合門檻，不是取平均數，也不是在辦公室測一次。Core Web Vitals 是重要使用者體驗訊號，但 Google 明確指出工具取得好分不保證搜尋排名第一；同樣，通過 CWV 亦不保證廣告 CPA 或轉換提升。
Field Data、Lab Data、RUM 與業務數據有甚麼分別？
| 資料 | 用途 | 限制 | 適合問題 |
|---|---|---|---|
| PageSpeed Insights Field／CrUX | 過去 28 日真實 Chrome 使用者經驗 | 低流量 URL 可能無數據，更新有延遲 | 真實 LCP／INP／CLS 是否長期達標 |
| Lighthouse Lab | 控制環境重現及技術診斷 | 一次模擬、不能真實量度 INP | 找 render blocking、圖片、JS 等機會 |
| Search Console CWV | 按 Mobile／Desktop 及相似 URL 群組監察 | 是群組及抽樣，不是每個 URL 即時監控 | 哪些模板及 URL 群組優先 |
| 自建 RUM | 逐頁、裝置、來源、版本收集真實體驗 | 要工程、私隱、抽樣及資料治理 | 廣告流量／市場／版本差異 |
| Google Ads／GA4／CRM | Click、Session、event、Lead、成交 | 歸因、Consent、身份與定義不同 | 速度問題是否與漏斗結果同時發生 |
PageSpeed Insights 同時提供 Field 與 Lab 資料；兩者不同並非工具壞了。Field 反映多種真實裝置和網絡，Lab 是固定環境的單次診斷。應把工具建議當成可測假設，不是照單全做的工作清單。
60 分鐘基線審核：先證明問題在哪一層
- 在 Google Ads Landing pages 報告列出高成本、高 Click 及主要 Final／Expanded landing URLs。
- 用手機真機、流動網絡及無登入狀態開啟 URL；保留所有 UTM／GCLID 測試參數。
- 確認 Redirect 次數、狀態碼、HTTPS、最終 URL、地區／語言及 Cookie banner。
- 在 PageSpeed Insights 記錄 Mobile／Desktop Field 與 Lab，不把兩者混成一個分數。
- 找出 LCP element、最慢 request、長任務、layout shift source 及第三方 script。
- 在 GA4 Landing page 報告按 Session source／medium、Device category 及頁面比較 Sessions、Key events。
- 用測試身份完成 CTA／Form／Call／WhatsApp；確認成功狀態及事件只出現一次。
- 把 Valid Lead、Qualified、Opportunity、Won 及 reason 與頁面／來源連回 CRM。
如果整站有流量但無查詢，使用網站有流量無查詢七層診斷；本篇不會把內容、Offer、信任或 Sales follow-up 問題全部包裝成速度問題。
Google Ads Click 多過 GA4 Session，是否代表頁面太慢？
可能，但不能只靠差額判定。Google Ads Click 與 GA4 Session 本身定義不同；同一人在短時間多次 Click 可能只形成一個 Session，Google Ads 亦會處理 invalid clicks。另一方面，使用者可以在 Google tag 完成載入前關閉頁面，Redirect 亦可能移除 GCLID／UTM，Consent 或瀏覽器設定可能阻止量度，Server／Firewall 亦可能只對部分地區或 IP 失敗。
- 確認 Ads auto-tagging、Final URL、tracking template 及 expanded URL。
- 在 URL 加測試 query parameter，驗證所有 Redirect 後仍存在。
- 確認 GA4 tag 在所有廣告 Landing Page 上可按 consent 正常執行。
- 按日期、頁面、Campaign、Device、Browser、Country 比較，而非全帳戶一個百分比。
- 檢查 Server log、CDN／WAF error、404／5xx、timeout 及實際頁面 availability。
UTM 及命名治理可配合UTM／GA4 命名指南；Google Ads 有 Click 無有效查詢則用Google Ads 七層診斷。
速度與 Google Ads Quality Score、Ad Rank 有甚麼關係？
Google Ads 的 Landing page experience 會看頁面是否相關、有用、易於瀏覽及符合廣告帶來的預期；auction-time ad quality 與 Landing Page 經驗可影響廣告是否顯示及位置。帳戶看到的 1–10 Quality Score 只是一個 Keyword 層診斷工具，不是 KPI，也不是 Auction 的直接輸入。
所以不要把「PageSpeed 分數 +10」直接換算成 CPC 會跌幾多，也不要只為 1–10 Quality Score 做無關改動。應同時檢查 Search term、Ad promise、Final URL、Mobile usability、內容相關性、CTA、速度及真實轉換。詳細判讀可看Google Ads Quality Score 診斷指南。
修復順序一：先處理 Redirect、Server 與 TTFB
- 廣告 Final URL 直接到 canonical HTTPS URL，避免 http → www → 語言 → slash 的多重跳轉。
- 檢查 DNS、TLS、CDN、WAF、Server、Database 及 backend call，不把所有問題交給前端壓圖。
- 使用合適頁面／object cache、CDN edge cache、壓縮及 HTTP caching；登入、Cart 或個人化頁面要分開策略。
- 減少首個 HTML 前不必要的 API、geolocation、cookie 或 A/B routing。
- 建立 uptime、5xx、TTFB 及 deployment 監察，否則平均分掩蓋間歇性失敗。
修復順序二：找出真正 LCP element
LCP 可能是 Hero 圖、H1／文字區塊、影片 poster 或背景圖。先在代表性裝置確認元素，再修：
- 讓 LCP resource 在初始 HTML 可被發現；不要用 JavaScript 到很後才插入。
- 不要對首屏 LCP 圖使用
loading="lazy"；需要時才使用fetchpriority="high"或 preload。 - 輸出正確尺寸及
srcset，使用合適 WebP／AVIF，但不要犧牲可讀性或產品細節。 - 壓縮、裁切及刪除手機看不到但仍下載的 desktop asset。
- 縮短 TTFB、CSS 阻塞、Font block 與資源載入延遲；不要只盯圖片檔案大小。
用 LCP breakdown 判斷應修哪一層
PageSpeed Insights 的 LCP breakdown 可把等待拆成 TTFB、Resource load delay、Resource load duration 及 Element render delay。先看哪段佔時，再選修復方式，避免只壓圖片或盲目加 preload：
| 分段 | 代表甚麼 | 先檢查 |
|---|---|---|
| TTFB | 瀏覽器等候首份 HTML | Redirect、Server、快取、資料庫與網絡 |
| Resource load delay | 導航開始到 LCP 資源開始下載的等待 | HTML 是否太遲發現資源、錯誤 lazy-load、CSS 背景圖或 JavaScript 插入 |
| Resource load duration | 下載 LCP 資源所需時間 | 圖片尺寸、格式、檔案量、網絡及 responsive image 是否選對 |
| Element render delay | 資源載完到 LCP 元素實際繪出的時間 | Render-blocking CSS、主線程長任務、字體、隱藏狀態與首屏遮罩 |
驗收時回看實際輸出的 HTML：真正的首屏 LCP <img> 不應 lazy-load；若設 fetchpriority="high"，只給已確認的 LCP 資源，不要替多張圖片一律提高優先級。CSS 背景圖只有在 trace 證明發現太遲時才考慮 preload，並須讓候選圖片與 srcset／sizes 相符，避免重複下載。改後用相同 URL 與裝置條件再測，對照四個分段及 HTML 屬性；Field data、Lab data 和 Lighthouse 分數要分開報告。
修復順序三：控制 JavaScript、Tag Manager 與第三方 Widget
Analytics、Ads、Meta、Heatmap、A/B Test、Chat、Consent、Video、Review、Personalization 及 CRM widget 都可能有商業用途，但一起放入首屏會增加 request、下載、解析、編譯及 main-thread work。
- 列出每個 script 的 owner、用途、觸發頁、資料、最後使用日期及刪除條件。
- 刪除重複 tag、舊 pixel、無人看的 Heatmap、過期 experiment 及多餘 library。
- 非首屏 widget 延後或按互動載入；必要 script 才保留在 critical path。
- 按供應商建議評估
async／defer，不要盲目修改致使追蹤或 consent 失效。 - 限制 Tag Manager 發布權限，建立版本、QA、效能 budget 及回滾流程。
非同步載入不會消除 JavaScript 執行成本；script 仍可能在使用者按 CTA 時佔用主線程，影響 INP。
修復順序四：防止 CLS、誤按與表單阻塞
- 為圖片、影片、iframe、廣告、Review、Map 及 widget 預留寬高或穩定容器。
- Cookie banner、促銷 bar、Chat 及驗證訊息不要把 CTA 突然推走。
- 優化字體載入，減少 fallback 與 web font 尺寸差造成的 layout shift。
- 表單錯誤在欄位附近保留位置並以文字說明，不只靠紅色或頁頂提示。
- CTA 在首屏可見不等於可按；要測試 sticky header、overlay、disabled state 及手機鍵盤。
CTA、表單、電話與 WhatsApp 的完整驗收見網站 CTA 指南。
圖片、字體、CSS 及影片應如何設 Performance Budget？
Performance Budget 應按頁面任務、裝置及真實基線設定，不必抄一個全行業 KB 數字。至少記錄：
- 首屏總 transferred bytes、request 數、第三方比例及 JavaScript 執行時間。
- LCP asset 最大尺寸、格式、發現時間與 request priority。
- Web font family／weight 數量、preload 及 fallback 行為。
- 影片 poster、iframe、autoplay、caption 及按互動載入策略。
- 每次 Campaign／CMS／Plugin 發布後的 Mobile Lab regression gate。
Budget 的用途是防止新 Hero、Tag 或 Widget 把已修好的頁面拖慢；不是為了做一張漂亮分數截圖。
如何證明速度改善真的影響轉換？
- 先固定頁面內容、Offer、Creative、Targeting、出價、季節及轉換定義。
- 建立改動前基線：Field／RUM、Ads Click、GA4 Session、CTA、Valid Lead、CRM 結果。
- 一次處理一個主要瓶頸或一組不可分割的技術修復，記錄版本與時間。
- 用同頁前後、受控 Experiment、逐模板 rollout 或可比較 cohort；避免同時全面改版。
- Lab 即時驗證 regressions，RUM 觀察新版本；CrUX／Search Console 需等待 28 日滾動資料。
- 同時看轉換率與 guardrail：錯誤率、Lead 質素、Revenue、Privacy、Accessibility。
沒有隨機對照時只能說「改善後同時觀察到」，不要宣稱速度造成全部升幅。正式實驗方法可配合Landing Page A/B Test 指南。
Landing Page 速度與 SEO／AIO／GEO 有何關係？
快速、穩定、可互動、主內容在 HTML 可見的頁面，較容易讓使用者及 crawler 取得內容；但 CWV、PageSpeed 90+、Schema 或允許 AI crawler 都不保證搜尋排名、AI 引用或推薦。AIO／GEO 仍需要清楚實體、直接答案、可核實資料、來源、內容責任、第三方佐證及更新日期。
不要為速度把關鍵文字只放在圖片、刪除必要證據，或用 skeleton／script 阻擋內容。速度修復要保留頁面真正決策價值。
14 日 Landing Page 速度修復流程
- 第 1 日：列出高成本／高價值 Landing URLs、裝置、Campaign、轉換及 CRM 結果。
- 第 2 日：完成真機、Field、Lab、Server、Tag 及 Click／Session 基線。
- 第 3 日：核對 Redirect、Final／Expanded URL、GCLID／UTM 與錯誤碼。
- 第 4–5 日：修 Server／TTFB／cache／CDN 及最明顯 availability 問題。
- 第 6–7 日：修 LCP resource、圖片、字體、CSS 與首屏優先級。
- 第 8–9 日：盤點 JavaScript、Tag Manager、第三方 widget 及 INP 長任務。
- 第 10 日：修 CLS、overlay、表單錯誤、CTA 可按及手機鍵盤。
- 第 11 日：重做端對端 event、Consent、GA4 及 CRM 對數。
- 第 12 日：建立 Performance Budget、deployment gate 及 rollback。
- 第 13–14 日：分批上線、監察 RUM／錯誤／漏斗，不過早用 CrUX 下結論。
15 項發布與月度驗收
- Final URL 直接到有效 HTTPS canonical，沒有不必要 Redirect。
- 主要市場、地區、裝置及未登入狀態均能載入。
- Mobile／Desktop Field 與 Lab 分開記錄。
- LCP、INP、CLS 以第 75 百分位及真實使用者為主要門檻。
- LCP element、resource、TTFB、load delay 與 render delay 已識別。
- 首屏 LCP 圖沒有錯誤 lazy-load，尺寸及 priority 合理。
- 第三方 script 有 owner、用途、觸發、權限及刪除條件。
- CTA、Menu、Selector、Form 在低階手機仍可回應。
- 圖片、iframe、banner、字體及錯誤訊息不造成明顯 shift。
- Consent 選擇後 tag 行為正確，不以速度為由繞過選擇。
- GCLID／UTM 經 Redirect 保留，GA4 Landing Page 可辨認。
- Click、Session、CTA、Valid Lead、Qualified、Won 分開。
- Google Ads Landing page experience／Quality Score 只作診斷。
- 改動有假設、版本、日期、觀察窗、success／stop／rollback。
- 每次新增 Hero、Plugin、Tag、Chat 或 Experiment 都重跑 gate。
常見問題
PageSpeed Insights 一定要 100 分嗎？
不需要。Lighthouse 90+ 是 Lab 的綠色範圍，但不代表真實使用者全部良好。優先看 Mobile Field／RUM、LCP／INP／CLS、主要任務、錯誤及業務結果。
Landing Page 幾多秒先算快？
不要只用完整 load time 一個數字。Google 的 Core Web Vitals 建議是 LCP ≤2.5 秒、INP ≤200 ms、CLS ≤0.1，並以手機與桌面的第 75 百分位判斷；任務完成仍要另行測試。
Click 多過 Session 就代表網站慢嗎？
不一定。Click 與 Session 定義不同，重複 Click、invalid click、Consent、Tag、Redirect、GCLID、瀏覽器及 Server 都可能造成差異。速度只是其中一個可驗證原因。
裝 CDN 或 Cache Plugin 是否一定會改善？
不一定。它可能改善特定 Server／資源問題，但不能修錯誤 Hero priority、龐大 JavaScript、第三方 widget、CLS、表單或內容／Offer。先找瓶頸再改。
Core Web Vitals 好會否提高 Google Ads Quality Score？
不能直接保證。Landing page experience 涵蓋相關性、有用性、易於瀏覽及廣告預期；1–10 Quality Score 是診斷工具。應用真實廣告及業務指標驗證。
速度改善會否保證 SEO 或 AI 引用？
不會。速度有助使用者及 crawler 取得內容，但 Google 明確指出 CWV 好分不保證頂部排名；AI 平台的引用與推薦亦由內容、證據、實體、來源、可抓取性及平台系統共同決定。
下一步：按數據檢查廣告及落地頁
如果速度或轉化問題集中在手機版、網站結構或表單承接，可了解 香港中小企網頁設計與網站重建服務；如需一併檢視搜尋意圖、關鍵字、轉化追蹤及合資格查詢，可了解 Google Ads 代營運服務。先按數據定位問題，再決定需要處理的項目。
官方資料與延伸閱讀
Google Ads／Analytics：Evaluate the performance of landing pages、About Quality Score、What matters for ad quality、Google Ads auction、Clicks and Sessions discrepancy、GA4 Landing page report及Verify and troubleshoot GA4。
速度／搜尋：Web Vitals、About PageSpeed Insights、Optimize LCP、Optimize INP、Optimize CLS、Load third-party JavaScript、Search Console Core Web Vitals report及Google Search page experience。
編輯與審閱：ITOB Group 編輯團隊；由ITOB Group 數碼營銷顧問團隊審閱。最後實質更新：2026 年 10 月 5 日。
本文按 Google Ads、Google Analytics、Google Search Central 及 web.dev 官方資料，以及 ITOB Group 的 Landing Page、廣告、分析、CRM 與發布驗收框架整理。工具、指標及平台介面會更新；技術改動應在 staging、代表性裝置及真實流量中分批測試。本文不保證廣告位置、CPC、Quality Score、轉換、排名、AI 引用、查詢或收入結果；詳見編輯政策與資料更正原則。
