分數滿了，客人還是說「你們網站好慢」
有位業主拿著一份 Lighthouse 報告來找我，截圖第一行是綠色的 100。
他說：「分數不是都滿了嗎？可是客人都說網站很慢。」
問題就在這裡。Lighthouse 跑分 100 分、Core Web Vitals 全綠——但實際開站體驗還是慢。
這不是 Lighthouse 有 bug，是它跟你客人的環境根本不是同一個世界。
Lighthouse 跑的是「模擬」：固定網速、固定裝置、沒有第三方 cookie、沒有廣告阻擋器。
真實用戶有的是什麼？ 通勤中的 4G、一台用了五年的舊手機、二十個瀏覽器 extension、還有一個剛開了視訊會議的視窗在背景吃頻寬。
你的 100 分，是在實驗室裡測出來的。他的「好慢」，是在捷運上手機滑了兩秒就滑走的真實體感。
這篇文章要解決的核心問題:Lighthouse 滿分但用戶覺得慢，怎麼辦？——7 個被 Lighthouse 忽略的優化細節。若想從網站骨架下手，可參考網站資訊架構完整指南。
> 詳細的速度優化測試見 [PageSpeed Insights](https://pagespeed.web.dev/) 跟 [Web Vitals](https://web.dev/vitals/) 官方文件。
細節一：第三方 Script 的非同步載入陷阱
網站通常會裝 Google Analytics、Facebook Pixel、Line Tag、客服系統等第三方 Script。
常見的「優化」是「用 async 載入」——但這是錯的。
為什麼 async 是錯的？
async 載入會讓 Script 隨時插入執行——可能在頁面渲染到一半時插入，造成 CLS(Cumulative Layout Shift)。
defer 才是正確的——Script 在 HTML 解析完後才執行，不會打斷渲染。
真正「聰明」的載入策略
第三方 Script 應該 lazy load——只在用戶互動後才載入。
業界常見的觀察：用這個策略，GA 載入時間從 1.2 秒降到 0,完全不打擾首屏渲染。
細節：字體載入的 Render Blocking
自訂字體 （Web Font） 是 LCP 的最大殺手。
瀏覽器等字體下載完才渲染文字——如果字體 500KB,LCP 就延遲 500KB / 網速。
優化策略
策略 1：用 font-display: swap（關鍵）
@font-face {
font-family: 'MyBrand';
src: url('/fonts/mybrand.woff2') format('woff2');
font-display: swap; /* 文字先用系統字體顯示,字體下載完再替換 */
}
策略 2：預載入關鍵字體
策略 3：用 variable font
Variable Font 是一個字體檔包含所有字重 （300-900）——比多個字體檔小 60-80%。
字體選擇的實戰建議
- 品牌字體用 1 個 variable font
- 避免使用 3 個字體（標題 + 內文 + 代碼）——2 個就夠了
細節三：圖片 Lazy Loading 的邊界條件
Lazy loading 圖片是標準做法——但有 3 個邊界條件：
邊界 1:Hero 圖片不要 lazy loading
Hero 圖片是 LCP(Largest Contentful Paint）的關鍵——如果 lazy load,LCP 會延遲到圖片「進入 viewport 才載入」。
<img src="hero.jpg" loading="lazy" alt="...">
<img src="hero.jpg" alt="...">
邊界 2：首屏圖片不要 lazy loading
首屏（above the fold）圖片一定要 eager load——否則 LCP 會失敗。
邊界 3：圖片 srcset 要完整
響應式圖片需要 srcset——在不同裝置下載合適大小的圖片。
<img src="image-800.jpg" alt="...">
這讓手機用戶下載 400px 的圖片，桌機用戶下載 1600px 的圖片——節省 75% 流量。
細節四：Long Task 喫掉主執行緒
JS 執行時間超過 50ms 就算「Long Task」——會阻塞主執行緒，讓頁面「卡住」。
找出 Long Task
用 Chrome DevTools 的 Performance 面板，找出黃色的 Long Task 警告。
解決 Long Task 的 3 個策略
策略 1:Web Worker
把 JS 重計算搬到 Web Worker——主執行緒不受影響。
策略 2:setTimeout 拆分
// ❌ 同步 500ms 計算
items.forEach(item => heavyProcess(item));
// ✅ 拆分到多個 setTimeout
function processInChunks(items, chunkSize = 50) {
const chunks = [...Array(Math.ceil(items.length / chunkSize))].map((_, i) =>
items.slice(i * chunkSize, i * chunkSize + chunkSize)
);
let i = 0;
function nextChunk() {
if (i >= chunks.length) return;
chunks[i].forEach(item => heavyProcess(item));
i++;
setTimeout(nextChunk, 0); // 把控制權還給瀏覽器
}
nextChunk();
}
策略 3:requestIdleCallback
requestIdleCallback(() => {
// 在瀏覽器空閒時執行非關鍵任務
prefetchNextPageData();
});
細節五：Preload、Prefetch、DNS-Prefetch 的使用時機
這 3 個 hint 容易搞混——以下是正確使用時機：
| Hint | 用途 | 使用時機 |
|---|---|---|
| `` | 預先下載當前頁面需要的資源 | Hero 圖片、關鍵字體、關鍵 CSS |
| `` | 預先下載下一頁的資源 | 訪客 80% 會去的下一頁 |
| `` | 預先解析 DNS | 第三方 CDN、跨網域資源 |
業界常見的坑:preload 用太多——瀏覽器只會預載最重要的 5-10 個資源，過多的 preload 反而拖慢渲染。
細節六：Vercel Edge 不是萬能解
Vercel Edge Functions 把計算搬到 CDN 邊緣——聽起來很美好。
但實際上 Edge Functions 有 3 個限制:
- 執行時間限制（通常 10-30 秒）
- 不能跑 Node.js 完整版（只能用 Web APIs）
- 冷啟動時間較長
實戰上的建議:Vercel Edge 適合「簡單的 SSR + 邊緣快取」,不適合「重計算」。
業界常見的觀察：把太多邏輯搬到 Edge,反而讓 edge function 變慢——因為 edge function 沒有 server 的本地資源。
> 詳細的 Cloudflare 邊緣運算見 Cloudflare 防禦 AI 駭客 與 Cloudflare 計價管線 ClickHouse 瓶頸事件。
細節七：行動裝置的 CPU 限制
Lighthouse 跑的 CPU 是「桌面級」——但用戶用的是手機，CPU 慢 5-10 倍。
行動裝置速度優化的 3 個關鍵
關鍵 1：減少 JS 執行時間
行動裝置的 JS 執行時間比桌面長 5-10 倍——如果桌面端執行 100ms，手機上可能 1 秒。
關鍵 2：避免大型 JS framework
React、Vue 的大型 app 在手機上會明顯變慢。
業界常見的觀察：手機端的 Lighthouse 分數（尤其 TBT）通常比桌面端差 30-50%。
關鍵 3：用 ``
讓瀏覽器更快 render 行動裝置的 status bar——節省 50-100ms。
檢測工具推薦
| 工具 | 用途 | 網址 |
|---|---|---|
| [PageSpeed Insights](https://pagespeed.web.dev/) | 詳細的 LCP、INP、CLS 分數 | https://pagespeed.web.dev/ |
| Chrome DevTools Performance | 找出 Long Task | Chrome DevTools |
| [Web Vitals](https://web.dev/vitals/) | Web Vitals 監控 | https://web.dev/vitals/ |
| WebPageTest | 多地點 + 多裝置測試 | https://www.webpagetest.org/ |
| Lighthouse CI | CI 整合速度檢測 | https://github.com/GoogleChrome/lighthouse-ci |
小結：速度優化是細節的總合
速度優化不是「做一個大改變」——是「累積 10 個小改變」。
Lighthouse 100 分不是終點——真實用戶的體驗才是。每個小細節（字體載入、第三方 Script、圖片規格、Long Task）都會影響 LCP、INP、CLS。想知道更多可看網站資訊架構完整指南。
實戰上的建議：每週跑一次 [PageSpeed Insights](https://pagespeed.web.dev/) + 比對本週 vs 上週的數字，持續優化比「一次大改」更重要。
