只要你搜過「網站速度測試」或「怎麼檢查 Core Web Vitals」，大概率都看過兩種做法。第一種是盯著 Lighthouse 分數不放，非得衝到 100 分才安心。第二種則是把 window.performance 印幾個數值出來，就覺得自己已經知道頁面為什麼慢了。老實說，這兩種都不夠。
Lighthouse 很適合做實驗室型檢測。它能快速抓出多餘的 JavaScript、過重圖片、阻塞渲染的資源，或者版本改動後的明顯退步。Window Performance API 則比較像你真正下場查案時會用的工具。它告訴你：瀏覽器到底卡在哪裡、哪個資源最慢、首屏什麼時候真正出現、畫面看起來好了但主執行緒是不是還沒喘過氣。
把這兩者放在一起看，性能優化才不會停留在「感覺變快了」。這對 SEO 和轉換率都很重要。LCP 太慢、互動反應太拖、CLS 一直跳，不只讓人煩，還會直接消耗掉你辛苦拿到的流量。
為什麼要同時看實驗室數據與瀏覽器實況
Lighthouse 的優點是快、標準化、容易比較。缺點也很明顯：它不等於真實使用場景。你的訪客不會全部用高階筆電接公司 Wi-Fi 來逛站。他們可能在通勤、可能用中階 Android，也可能被第三方腳本、彈窗、字型檔拖慢整體體驗。
這時候 window.performance 的價值就出來了。因為你可以開始回答更實際的問題：
- 瓶頸是在初始 HTML、伺服器回應，還是第三方腳本？
- Hero 區塊遲遲不出現，到底是圖片太重、字型太慢，還是渲染被卡住？
- 頁面看起來已經載完了，為什麼點按還是鈍鈍的？
有了這種對照，你才不會一直在錯的地方用力。
Lighthouse 要怎麼看，才不會只剩一個分數
最直接的方式還是 Chrome DevTools。打開頁面，按 F12，切到 Lighthouse 分頁，選 Mobile 或 Desktop，然後跑一次分析。如果你要拿來比對不同版本、或者放進 CI 流程，CLI 也很適合。
在進 DevTools 前，也可以先把 URL 丟進 SEO Analyzer 看一輪，先判斷哪些頁面最值得優先檢查，特別是載入表現和行動裝置體驗。
真正該看的，通常不是最上面的總分，而是下面這些細節：
- 未使用的 JavaScript 太多
- CSS 或腳本阻塞渲染
- 首屏圖片太重
- 第三方腳本把 TBT 拉高
一旦你用這種方式讀報告，Lighthouse 就不只是「評分工具」，而是排優先級的地圖。
哪些指標最值得先盯
不用把所有縮寫都背起來。以 SEO、UX 和轉換為目標時，我會優先看這幾個：
- LCP： 主要內容多久才出現在眼前。
- INP： 使用者互動後，頁面回應得快不快。
- CLS： 版面在載入時會不會亂跳。
- FCP： 空白頁面什麼時候結束。
- TBT： 很適合在實驗室環境裡判斷主執行緒是否被長任務卡住。
很多舊文章還會花很大篇幅談 TTI 或 FID。理解背景沒有問題，但如果你今天要做優先級判斷，LCP、INP、CLS、TBT 通常更有用。
Window Performance API 真正能補上的資訊
到這一步，才算真正進入「查原因」的階段。
performance.getEntriesByType('navigation') 可以看導覽時間。resource 可以抓慢資源。paint 可以幫你確認畫面第一次有內容的時點。如果你想觀察 LCP、CLS 或 long task 這種較新的事件，則更建議用 PerformanceObserver。
1const nav = performance.getEntriesByType('navigation')[0]; 2const resources = performance.getEntriesByType('resource'); 3 4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd); 5console.log('Load event:', nav.loadEventEnd); 6console.log( 7 'Top 5 slowest resources:', 8 resources.sort((a, b) => b.duration - a.duration).slice(0, 5) 9);
1const observer = new PerformanceObserver((list) => { 2 for (const entry of list.getEntries()) { 3 console.log(entry.entryType, entry.startTime, entry.duration || entry.value); 4 } 5}); 6 7observer.observe({ type: 'largest-contentful-paint', buffered: true }); 8observer.observe({ type: 'layout-shift', buffered: true }); 9observer.observe({ type: 'longtask', buffered: true });
如果你想在正式站上穩定收集 INP，最好還是接到自己的 RUM 流程，或採用 web-vitals 類型的實作，不要只靠臨時拼湊的腳本。
真正有意思的地方，在於你把測試條件切換到不同網路後再看一次。很多頁面在辦公室 Wi-Fi 下看起來「還行」，一旦換成 Fast 3G 或中階手機，問題就全部浮出來了。
一套實際上真的好用的工作流
我不建議把性能測試搞成一套很重的儀式。重點是順序要對：
- 先用 Lighthouse 找出高風險頁面與主要方向。
- 再用
window.performance往下追，找出慢在哪個資源、哪個階段。 - 接著對照真實流量數據或 Search Console，確認這不是只有實驗室才會出現的問題。
- 修正後回到同樣的裝置與網路條件再測一次。
如果報告已經明確指出檔案過重，部署前可以順手用 JavaScript Compressor、CSS Compressor 與 HTML Compressor 先把可減的體積減下來。
結語
好的網站效能測試，不是停在「這次跑了幾分」。而是你是否能說清楚：這頁為什麼慢、哪個環節在拖、哪一個修正最值得先做。
Lighthouse 給你第一個警報，Window Performance 幫你把警報拆成真正可執行的診斷。如果你想先從全站角度抓出問題頁，再往下做深挖，可以先把 URL 丟進 SeoSpeedup，再用瀏覽器層級的數據把原因查清楚。
