客人等上菜不會超過 3 分鐘，客人等網頁也不會超過 3 秒
先講一個場景。
一位客戶的網站上線後第一個月沒什麼問題。第二個月他開始跟我反映：「最近感覺網站好像變慢了。」
我去看了一下。網站本身沒有變——慢的是他的客人手上的裝置。
他把同一個網址傳給朋友看，朋友在捷運上用 4G 開，首屏跑 4.2 秒。他自己用辦公室的網路開，1.1 秒。他以為網站壞了，但網站其實只是在他朋友的手機上活不過三秒。
餐廳客人等上菜超過 3 分鐘就會抱怨;網站訪客超過 3 秒沒看到內容就會離開。
Google 的研究顯示：網頁載入時間從 1 秒延遲到 3 秒，跳出率增加 32%。
速度不是「技術問題」，是「商業問題」。你那個慢下來的網站，不是工程問題，是每個月少掉的詢問單。
這篇文章從 7 個面向拆解網站速度優化，讓你的網站快到讓訪客「感覺不到載入」。想避開常見地雷，可讀 網站速度優化:被忽略的細節。
> 詳細的速度檢測見 [PageSpeed Insights](https://pagespeed.web.dev/) 與 [Web Vitals](https://web.dev/vitals/) 官方文件。
第一章：Core Web Vitals 完整解析 — 先搞懂 LCP / INP / CLS
[Core Web Vitals](https://web.dev/vitals/) 是 Google 2026 年最關鍵的排名因素之一——由 3 個指標組成:
指標 1:LCP(Largest Contentful Paint)— 最大內容繪製
LCP 衡量「頁面主要內容多久渲染出來」。
- 好:LCP < 2.5 秒
- 需改進:LCP 2.5-4.0 秒
- 差:LCP > 4.0 秒
常見的 LCP 殺手:
- Hero 圖片太大（沒壓縮）
- 自訂字體載入慢
- 第三方 Script 阻塞渲染
指標 2:INP(Interaction to Next Paint)— 互動到下次繪製
INP 衡量「用戶點擊後，頁面多久回應」。
- 好:INP < 200ms
- 需改進:INP 200-500ms
- 差:INP > 500ms
常見的 INP 殺手:
- JS 執行時間太長（Long Task）
- 主執行緒被阻塞
- 大量 DOM 元素
指標 3:CLS(Cumulative Layout Shift)— 累計版面配置轉移
CLS 衡量「頁面載入時，內容跳動的程度」。
- 好:CLS < 0.1
- 需改進:CLS 0.1-0.25
- 差:CLS > 0.25
常見的 CLS 殺手:
- 圖片沒指定寬高
- 字體載入後字級變化
- 動態插入內容（廣告、彈窗）
三個指標的關係
這 3 個指標共同決定「用戶體驗分數」——單一指標好，不代表用戶體驗好。
第二章：圖片優化 — 佔網站載入時間 50-80% 的速度殺手
圖片是網站最大的載入負擔——佔 50-80% 的總下載時間。
圖片優化 5 大策略
策略 1：選對圖片格式
| 格式 | 適用 | 壓縮率 |
|---|---|---|
| WebP | 通用（首選） | 比 JPEG 小 25-35% |
| AVIF | 現代瀏覽器 | 比 WebP 再小 20% |
| JPEG | 舊瀏覽器 fallback | 標準 |
| PNG | 透明背景 | 較大 |
| SVG | icon、logo | 極小 |
實戰上的建議:全部用 WebP（主） + JPEG(fallback)。
策略 2：響應式圖片
<img src="image-800.jpg" alt="...">
手機下載 400px，桌機下載 1600px — 節省 75% 流量。
策略 3:lazy loading
<img src="image.jpg" loading="lazy" alt="...">
但 Hero 圖片不要 lazy loading — LCP 會失敗。
策略 4：現代壓縮工具
用 Squoosh 或 TinyPNG 預先壓縮 — 通常可小 50-70%。
策略 5:CDN 圖片優化
用 [Cloudflare Images](https://www.cloudflare.com/products/images/) 或 imgix — 自動轉 WebP + 自動響應式。
第三章：JavaScript 管理 — 消滅渲染阻擋，讓頁面不再「假死」
JS 載入太慢 = 頁面「假死」 — 用戶點擊沒反應。
JS 優化 5 個關鍵
關鍵 1:defer / async 正確使用
defer:Script 在 HTML 解析後執行（不阻塞渲染）async:Script 隨時可執行（可能阻塞渲染）defer用於「頁面需要的 Script」,async用於「獨立 Script」（如 GA）
關鍵 2:Code splitting
// ❌ 全部打包
import HeavyPage from './HeavyPage';
// ✅ lazy load
const HeavyPage = lazy(() => import('./HeavyPage'));
關鍵 3:Tree shaking
確認 build 工具搖掉了沒用到的代碼——Next.js 預設做。
關鍵 4：避免大型 framework
如果只是簡單頁面，原生 JS 或 Preact 比 React / Vue 小 50-80%。
關鍵 5:Long Task 預防
JS 執行時間 > 50ms 算 Long Task——用 Web Worker 或 setTimeout 拆分。
第四章：瀏覽器快取 — 讓回頭客體驗秒開
瀏覽器快取讓回頭客不用重新下載資源。
快取設定範例
> 靜態資源(圖片、CSS、JS)快取 1 年
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 1y;
add_header Cache-Control "public, max-age=31536000, immutable";
}
## HTML 快取 1 小時
location ~* \.html$ {
expires 1h;
add_header Cache-Control "public, max-age=3600";
}
注意:HTML 改版要清除快取——常用 versioning(?v=2）。
第五章：字體優化 — 消滅 FOUT 文字閃爍
自訂字體沒優化 = FOUT(Flash of Unstyled Text) — 文字載入前先顯示系統字體，造成視覺閃爍。
字體優化 3 招
招 1:font-display: swap（關鍵！）
@font-face {
font-family: 'MyBrand';
src: url('/fonts/mybrand.woff2') format('woff2');
font-display: swap; /* 立即用系統字體,字體下載完再切換 */
}
招 2：預載入關鍵字體
招 3:Variable Font
1 個 variable font 包含所有字重 — 比多個字體小 60-80%。
第六章：CDN 設定 — 讓全球訪客都離你最近
CDN (Content Delivery Network) 把資源分散到全球節點 — 訪客從最近的節點下載。
推薦 CDN
| CDN | 特色 | 價格 |
|---|---|---|
| Cloudflare | 免費版就很好用，整合 DNS + WAF | 免費起 |
| Fastly | 進階 Varnish-based， 大型網站 | 付費 |
| CloudFront | AWS 整合 | 付費 |
業界常見的觀察:Cloudflare 免費版就比不用 CDN 強 5-10 倍。
第七章：HTTP/2 與 HTTP/3 — 現代傳輸協定的加速邏輯
HTTP/2 與 HTTP/3 是現代網站的傳輸標準 — 多路復用 + header 壓縮 讓網站更快。
HTTP/2 vs HTTP/3
| 特性 | HTTP/2 | HTTP/3 |
|---|---|---|
| 多路復用 | ✅ | ✅ |
| Header 壓縮 | ✅ | ✅ |
| 連線遷移 | ❌ | ✅ |
| TLS 1.3 | 選擇性 | 必須 |
| 速度 | 快 | 更快 |
實戰上的建議:Cloudflare 預設啟用 HTTP/3 — 只要開啟，自動升級。
7 個面向的整合檢查清單
每週跑一次 [PageSpeed Insights](https://pagespeed.web.dev/) + [Web Vitals](https://web.dev/vitals/) 檢查：
- LCP < 2.5 秒
- INP < 200ms
- CLS < 0.1
- 圖片全部用 WebP
- 圖片有 srcset + lazy loading
- JS 用 defer
- 字體用 font-display: swap
- CDN 啟用
- HTTP/3 啟用
任何一個不通過，就是優化點。
結語：速度優化是 1% 的累積
速度優化不是「一個大改變」 — 是 100 個 1% 的累積。
每個 1% 的優化（圖片壓縮 1%、字體減重 1%、JS 拆分 1%…）累積起來，LCP 從 4 秒降到 2 秒 — SEO 排名 + 轉換率雙提升。
實戰上的建議:每週修一個 1% — 比「一次大改」更持續、更穩定。
