為什麼需要量測工具？#
「我自己用起來覺得很順」這種主觀感受並不能代表網站效能好。每個使用者所處的網路環境、裝置規格、瀏覽器版本都不同，光憑體感判斷會嚴重失真。更何況搜尋引擎也是透過自己的爬蟲來評估網站，演算法不會在意你個人的感受。
要客觀地了解一個網站到底快不快，必須仰賴專業的量測工具。本章會介紹三個目前業界常用的工具，並進一步示範如何把 Lighthouse 整合進 CI 流程，把效能檢測做成自動化的守門員。
- Google PageSpeed Insights
- WebPageTest
- Lighthouse 與 Lighthouse CI
Google PageSpeed Insights#
PageSpeed Insights 是門檻最低的工具，只要在瀏覽器打開官方網址，把要檢測的 URL 貼進去就能立刻看到結果。它會分別呈現手機版與電腦版的分數，並列出主要的效能指標、資源大小統計與改善建議。
值得注意的是，PageSpeed Insights 背後其實也是用 Lighthouse 的資料計算出來的。差別在於它的呈現方式比較精簡、操作極為直覺，連手機都能直接量測，因此非常適合「快速看一下這個網站大概表現如何」這類需求。
雖然 PageSpeed Insights 用起來很方便，但它呈現的細節遠比直接執行 Lighthouse 來得少。需要深入分析時還是建議用 Lighthouse 取得完整報告。
WebPageTest#
WebPageTest 最大的優勢是「可以輕鬆切換不同瀏覽器、不同地理位置進行檢測」。Lighthouse 與 PageSpeed Insights 是 Google 自家工具，對 Chrome 的支援自然最好；如果想知道網站在 Firefox、Edge 或是不同國家節點下的表現，WebPageTest 是更合適的選擇。
它的設定選項也比較豐富，可以指定連線速率、測試次數、測試地點等等。代價是執行速度偏慢，每次跑完一輪要等比較久。
Google Lighthouse#
Lighthouse 是日常開發中最推薦的主力工具。它一次會輸出多個面向的分數：
- Performance
- Accessibility
- Best Practices
- SEO
- Progressive Web App（PWA）
除了給出分數以外，它還會針對每個指標列出具體的改進建議，例如哪張圖片太大、哪段 JavaScript 阻塞了渲染等等。對開發者來說等於是「免費的效能顧問」。
Lighthouse 的執行方式有兩種：
- 安裝 Chrome 擴充功能後，在任何網站上點擊 Generate Report。
- 開啟 Chrome DevTools，切到 Lighthouse 分頁直接執行。
兩種方式產出的報告完全相同，差別只在使用習慣。
Lighthouse CI：把效能檢測接進 CI/CD#
前面三個工具都是「網站部署完成之後」才能跑的。但實務上一次推版可能涵蓋好幾十個 commit 與 PR，如果某個 commit 拖垮了效能，事後想追查是哪一筆改動造成的會非常困難。
Lighthouse CI 就是為了這個情境而生。它把 Lighthouse 的檢測能力包裝成 CLI，可以在 CI/CD 流程中自動執行；甚至可以細到「每次 commit 都跑一次，並比對前後分數差異」。配合 GitHub App 還能直接在 Pull Request 上做 status check，讓問題在 code review 階段就被攔下來。
實作示範#
下面以 GitHub Actions 為例，示範一個最小可用的 Lighthouse CI 設定。整體流程的目標是：
- 每次 push 都自動跑 Lighthouse，未達標就讓 CI 失敗。
- 每次發 Pull Request 時自動掛上 status check，未達標就標記為 failed。
步驟一：安裝 Lighthouse CI GitHub App#
到 Lighthouse CI 的 GitHub App 頁面安裝到目標 repository，安裝完畢會拿到一組 token。把 token 加到 repository 的 Settings ➡️ Secrets，命名為 LHCI_GITHUB_APP_TOKEN。
步驟二：撰寫 GitHub Actions workflow#
在專案根目錄建立 .github/workflows/lighthouse-demo.yml：
name: Lighthouse CI demo
on: [push]
jobs:
lhci:
name: Lighthouse CI
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Use Node.js
uses: actions/setup-node@v1
with:
node-version: 12.x
- name: Install and build
run: |
yarn
npm run build
- name: Run Lighthouse CI
run: |
npm install -g @lhci/cli@0.3.x
lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}重點在於最後一步：執行 lhci autorun，並把上一階段拿到的 token 透過環境變數傳進去。temporary-public-storage 表示報告會上傳到 Google 提供的暫存空間，方便檢視。
步驟三：定義通過 / 不通過的條件#
只是跑 Lighthouse 還不夠，必須訂出「分數低於多少時要 fail」這樣的規則。在專案根目錄建立 .lighthouserc.json：
{
"ci": {
"assert": {
"preset": "lighthouse:no-pwa",
"assertions": {
"categories:performance": [
"warn",
{ "aggregationMethod": "optimistic", "minScore": 0.93 }
],
"categories:accessibility": [
"error",
{ "aggregationMethod": "optimistic", "minScore": 0.95 }
]
}
}
}
}這份設定的意思是：
- Performance 分數低於 0.93 時顯示 warning。
- Accessibility 分數低於 0.95 時直接報 error，CI 會 fail。
完整的 assertion 設定可以參考 Lighthouse CI 的官方文件，可以針對個別 metric（例如 LCP、TBT）設定門檻，彈性非常高。
一開始不用把門檻設得太嚴。建議先量測現況，再以「不退步」為基礎逐步往上拉，否則一開始就高標反而會讓團隊一直在處理紅色 CI。
整合後的效果#
設定完成後，每次 push 與 PR 都會自動跑 Lighthouse；未達門檻時 status check 會直接顯示 failed。點進去報告還能看到該 commit 造成各個指標的具體變化，等於是把效能監控做進日常 code review 流程，而不是等使用者抱怨才發現問題。
本章重點#
- 量測工具是效能優化的起點，沒有量測就沒有優化。
- PageSpeed Insights 上手最快，WebPageTest 適合跨瀏覽器與跨地區測試，Lighthouse 是日常主力。
- Lighthouse CI 把效能檢測整合進 CI/CD，可以攔截造成退化的 commit / PR。
- 配合
.lighthouserc.json可以細緻設定通過條件，是團隊化效能管理的關鍵。