速度就是金錢，這不是比喻
你的 Landing Page 載入要幾秒？如果你不知道，現在就去 Google PageSpeed Insights 測一下。
Google 的數據很殘酷：
- 頁面載入時間從 1 秒增加到 3 秒，跳出率增加 32%
- 從 1 秒增加到 5 秒，跳出率增加 90%
- 從 1 秒增加到 10 秒，跳出率增加 123%
換句話說，如果你的 Landing Page 需要 5 秒才能載入完成，將近一半的人在看到你的內容之前就離開了。你的文案寫得再好、設計做得再精緻，都是做給不存在的觀眾看的。
更直接地算一筆帳：假設你的廣告每天帶來 1,000 個訪客，頁面載入時間是 5 秒，跳出率 50%。如果你把載入時間壓到 2 秒，跳出率降到 30%，你每天就多留住 200 個人。如果轉換率是 5%，那就是每天多 10 個客戶。一個月多 300 個客戶。
速度優化不是什麼技術人員才需要關心的事情。它是行銷人員的 ROI 問題。
先搞清楚你的頁面慢在哪裡
在開始優化之前，你需要知道問題出在哪裡。不要盲目地做一堆優化，結果改到了不是瓶頸的地方。
Google PageSpeed Insights
最基本也最好用的工具。輸入你的網址，它會給你一個 0-100 的分數，還會列出具體的問題和改善建議。90 分以上算優秀，50-89 分需要改善，50 分以下是緊急狀況。
它會同時給你行動裝置和桌機的分數。先看行動裝置的分數，因為超過七成的廣告流量來自手機，而且手機的網路速度和處理能力都比桌機差。
GTmetrix
另一個好用的工具，除了分數之外還會給你一個「瀑布圖」（Waterfall Chart），讓你看到頁面上每個檔案的載入順序和時間。你可以很清楚地看到是哪個檔案拖慢了整個頁面。
Chrome DevTools
打開 Chrome 瀏覽器，按 F12 進入開發者工具，切到 Network 分頁，然後重新載入頁面。你可以看到每個檔案的大小和載入時間。按照大小排序，最大的那幾個檔案通常就是你的優化目標。
關鍵指標：
- LCP（Largest Contentful Paint）：頁面上最大元素載入完成的時間。目標是 2.5 秒以內
- FID / INP（Interaction to Next Paint）：使用者第一次互動到頁面回應的時間。目標是 200 毫秒以內
- CLS（Cumulative Layout Shift）：頁面載入過程中元素的位移程度。目標是 0.1 以下
這三個指標就是 Google 的 Core Web Vitals，它們不只影響使用者體驗，也會影響 Google 的搜尋排名。
圖片：最大的速度殺手
根據統計，圖片佔了一般網頁總大小的 50-70%。這意味著圖片優化是速度優化裡投資報酬率最高的一件事。
用 WebP 格式取代 JPEG 和 PNG
WebP 是 Google 開發的圖片格式，比 JPEG 小 25-30%，但視覺品質幾乎一樣。所有現代瀏覽器都支援 WebP（包括 Safari）。如果你還在用 JPEG，換成 WebP 是最簡單的提速方法。
如果擔心極少數不支援 WebP 的舊瀏覽器，可以用 HTML 的 <picture> 元素做降級處理：瀏覽器支援 WebP 就載入 WebP，不支援就載入 JPEG。
壓縮圖片
很多人從相機或圖庫下載的圖片動輒 2-5MB，直接放上網頁。這完全不必要。一張 Landing Page 上用的圖片，壓縮到 100-200KB 就能有很好的視覺效果。
免費的壓縮工具：TinyPNG（支援 WebP、JPEG、PNG）、Squoosh（Google 出品，可以即時預覽壓縮效果）。
設定正確的圖片尺寸
如果你的圖片區域在頁面上只有 600px 寬，就不要上傳一張 3000px 寬的圖片。瀏覽器雖然會自動縮放，但它還是得先下載完整的 3000px 圖片。用圖片編輯工具把尺寸調整到實際需要的大小。
對於高解析度螢幕（Retina Display），圖片寬度設定為顯示寬度的 2 倍就夠了。600px 的區域用 1200px 的圖片，不需要 3000px。
延遲載入（Lazy Loading）
頁面載入的時候，不需要一次把所有圖片都載入。使用者看不到的圖片（在螢幕下方的），等他滾到那個位置再載入就好。
HTML 原生支援延遲載入，只要在 <img> 標籤加上 loading="lazy" 就可以了。不需要安裝任何 JavaScript 套件。
但有一個重要的例外：**Hero Section 的主圖不要延遲載入。**那是頁面上最重要的視覺元素，使用者一進來就會看到，必須最優先載入。
程式碼瘦身：砍掉用不到的東西
圖片之外，CSS 和 JavaScript 是第二大的速度殺手。
移除用不到的 CSS
很多人用 Bootstrap 或 Tailwind CSS 這類框架來建 Landing Page。問題是這些框架的完整 CSS 檔案通常有幾百 KB，但你的 Landing Page 可能只用到了其中 10% 的樣式。
如果用 Tailwind CSS，記得開啟 PurgeCSS（Tailwind v3 以上內建），它會自動移除沒有用到的樣式。一個完整的 Tailwind CSS 檔案從 3MB 瘦身到 10KB 是常有的事。
減少 JavaScript
Landing Page 不需要太多 JavaScript。如果你只是要一個靜態的頁面加上一個表單，原生的 HTML 和 CSS 就能搞定大部分的事情。
檢查一下你的頁面有沒有載入了不需要的 JavaScript 套件。一個 jQuery 就 87KB，一個 React 加 ReactDOM 就 40KB。如果你沒有用到它們的功能，就不要載入。
壓縮和合併
CSS 和 JavaScript 檔案裡的空格、換行、註解在瀏覽器執行的時候是不需要的。用壓縮工具把它們移除，通常可以減少 30-50% 的檔案大小。
如果你用 Webpack、Vite 或其他打包工具，它們通常都有內建的壓縮功能。確保在正式環境（Production）有開啟壓縮。
延遲載入非關鍵的 JavaScript
追蹤碼（Facebook Pixel、Google Analytics）、聊天機器人、社群分享按鈕——這些東西不影響頁面的首次渲染，不需要在頁面載入的第一時間就載入。
在 <script> 標籤加上 defer 或 async 屬性，讓瀏覽器先把頁面內容渲染出來，然後才載入這些腳本。
伺服器和 CDN：距離也是速度
你的網頁檔案存在伺服器上，使用者的瀏覽器從伺服器下載這些檔案。兩者之間的物理距離會影響下載速度。
如果你的伺服器在美國，但你的客戶大多在台灣，每個檔案都要跨越太平洋來回一趟。即使頻寬夠大，光是網路延遲就可能增加 200-300 毫秒。
CDN（Content Delivery Network）
CDN 在全世界有很多節點，會把你的靜態檔案（圖片、CSS、JavaScript）複製到離使用者最近的節點。台灣的使用者就從台灣的節點載入，日本的使用者就從日本的節點載入。
常見的 CDN 服務：Cloudflare（有免費方案）、AWS CloudFront、Google Cloud CDN。
如果你的 Landing Page 是用 WordPress 或其他 CMS 建的，大部分的 CDN 服務都有一鍵安裝的外掛，設定起來不會太複雜。
瀏覽器快取
設定正確的快取標頭（Cache Header），讓瀏覽器把已經下載過的檔案存在本地。使用者第二次造訪的時候，就不用重新下載所有檔案了。
對於 Landing Page 來說，圖片和字型可以設定比較長的快取時間（例如一年），因為它們不常變動。CSS 和 JavaScript 可以設定短一點（例如一週），方便你更新的時候使用者能拿到最新版本。
GZIP / Brotli 壓縮
在伺服器端啟用 GZIP 或 Brotli 壓縮，可以把 HTML、CSS、JavaScript 這類文字檔案壓縮到原本的 20-30%。大部分的現代伺服器都支援這個功能，只需要在設定檔裡開啟。
Brotli 比 GZIP 壓縮率更好（通常再小 15-20%），而且所有現代瀏覽器都支援。如果你的伺服器支援 Brotli，優先使用它。
字型：被忽略的效能殺手
自訂字型是另一個常被忽略的速度問題。
一個中文字型檔案可能有 5-10MB（因為中文字元量大），即使是英文字型也有 50-200KB。如果你載入了多個字重（Regular、Bold、Light），檔案大小會翻倍。
字型優化的方法：
字型子集化（Subsetting）
如果你用的是中文字型，你不需要載入所有四萬多個字元。用工具把字型檔案裁剪成只包含你頁面上實際用到的字元。一個 5MB 的字型檔案可能縮減到 200KB。
Google Fonts 的中文字型已經自動做了子集化，會根據頁面內容動態載入需要的字元。
用 font-display: swap
在 CSS 裡設定 font-display: swap，瀏覽器會先用系統字型顯示文字，等自訂字型載入完成後再替換。這樣使用者不會看到一片空白等字型載入。
不要載入太多字重
大部分的 Landing Page 只需要兩個字重：Regular 和 Bold。不需要 Thin、Light、Medium、SemiBold、ExtraBold、Black 全部載入。每多一個字重就多一個檔案要下載。
考慮用系統字型
如果你的 Landing Page 不需要特殊的品牌字型，用系統字型是最快的選擇——完全不需要下載。font-family: system-ui, -apple-system, sans-serif 在各個作業系統上都能顯示出好看的字型。
第三方腳本：速度的隱形小偷
Landing Page 上通常會安裝一些第三方腳本：Facebook Pixel、Google Analytics、Google Tag Manager、聊天機器人、熱力圖工具、A/B 測試工具……
每一個腳本都是一個額外的 HTTP 請求，都需要從外部伺服器下載，都會佔用瀏覽器的處理資源。裝了五六個追蹤工具之後，它們加起來的載入時間可能就超過一秒了。
第三方腳本的管理原則：
只留必要的
你真的需要同時裝 Facebook Pixel、Google Analytics、Hotjar 和 Mixpanel 嗎？如果兩個工具提供的資訊有重疊，選一個就好。
用 Google Tag Manager 統一管理
不要在頁面上直接貼一堆追蹤碼。用 GTM 來管理所有的追蹤腳本，可以更好地控制載入順序和觸發條件。
設定觸發條件
不是每個腳本都需要在頁面載入的時候就執行。比如聊天機器人可以等使用者在頁面上停留 5 秒之後才載入，熱力圖工具可以等使用者開始滾動頁面之後才載入。
定期檢查
每隔一兩個月檢查一下頁面上有哪些第三方腳本。你會發現有些腳本是半年前測試的時候裝上去的，測試早就結束了但腳本還在。把不再需要的腳本移除。
實戰優化清單
講了這麼多，整理成一個可以立刻執行的清單：
優先級高（效果最大、執行最簡單）：
- 把所有圖片轉成 WebP 格式並壓縮到 200KB 以下
- 在非首屏圖片加上
loading="lazy" - 在第三方腳本加上
defer或async - 開啟伺服器端的 GZIP 或 Brotli 壓縮
- 設定瀏覽器快取標頭
優先級中（需要一些技術調整）：
- 移除沒用到的 CSS 和 JavaScript
- 設定 CDN
- 字型子集化或改用系統字型
- 移除不必要的第三方腳本
優先級低（進階優化）：
- 實施關鍵 CSS 內聯（Critical CSS Inlining）
- 預連接關鍵的第三方網域（Preconnect）
- 考慮使用靜態網頁生成器
每做完一項，用 PageSpeed Insights 測一下分數的變化。你會發現光是做完前五項，分數就能提升 20-30 分。
把速度優化當成跟表單優化和文案撰寫一樣重要的事情來做。速度是所有優化的基礎——頁面都載不出來，其他的優化都沒有意義。
如果你需要專業的網站架設與技術支援來處理這些技術層面的優化，從伺服器設定、CDN 配置到程式碼精簡，專業的技術團隊可以幫你把 PageSpeed 分數從紅區拉到綠區。
