Lighthouse 節流設定全解：Simulated vs DevTools 節流、CPU 4x 乘數與 CI 環境校準

Lighthouse 的節流設定在哪，預設值是什麼

跑 Lighthouse 之前先確認節流設定開在哪，這件事比大多數人想的重要。同一個頁面，節流設定不同可以讓 LCP 從 1.2s 變成 3.8s，Performance 分數從 92 掉到 61。不是頁面變慢了，是測試條件不一樣。

Lighthouse 的節流設定有三個入口：

• Chrome DevTools：Lighthouse 面板右上角的齒輪圖示，展開後可以看到「Throttling」下拉選單
• CLI：--throttling-method 和 --throttling.* 系列 flag
• Node.js API：config.settings.throttling 物件

DevTools 介面的預設選項是「Simulated throttling」，下拉選單還有「DevTools throttling」可以切換。CLI 預設同樣是 simulated，加 --throttling-method=devtools 切換。

預設的節流參數：

參數	Mobile 預設	Desktop 預設
Throttling 方法	Simulated	Simulated
RTT	150 ms	40 ms
下行頻寬	1.6 Mbps	10 Mbps
上行頻寬	750 Kbps	10 Mbps
CPU 乘數	4x 慢速	1x（無節流）

這組數字代表的是「Slow 4G」網路加上「mid-tier Android 手機」。如果你的目標受眾都在光纖環境用桌機，mobile 模式的分數對你的參考價值有限。但大多數網站的實際用戶混合了各種裝置，mobile preset 是合理的基準線。

Simulated 節流：不是真的限速，是數學估算

這是大多數人誤解最深的地方。Lighthouse 預設的 Simulated throttling 不是真的把你的網路速度限制到 1.6Mbps，也不是真的讓你的 CPU 變慢 4 倍。它是這樣運作的：

1. Lighthouse 在沒有任何節流的情況下，完整載入頁面一次，收集所有資源的下載時間、大小、執行時間
2. 用這組原始數據，套入一個數學模型，估算如果在 Slow 4G + 4x CPU 環境下，各資源的載入順序和時間會是什麼
3. 根據估算出的時間軸，計算 LCP、TBT、CLS 等指標

這個方法的主要優點是速度快、變異數低。同一個頁面跑五次，分數浮動通常在 ±3 分以內，適合快速迭代時的基準比較。

但它有一個根本限制：模型的準確度取決於頁面的行為有多接近模型的假設。當你遇到這些情況時，simulated 估算容易出問題：

• 頁面有複雜的 render-blocking 邏輯，實際載入順序依賴網路條件動態變化
• 有大量第三方腳本，各自有獨立的載入行為
• 後端回應時間（TTFB）在真實慢速網路下會比快速網路更長
• Service Worker 或快取策略依賴實際網路行為

還有一個判斷 simulated 是否準確的信號：如果 simulated 指標值比你實際跑的 DevTools throttling 結果還要好，通常代表模擬出現誤差，而不是真的表現更好。這種情況要切到 DevTools throttling 驗證。

PageSpeed Insights 永遠使用 simulated throttling，因為它要在 Google 的伺服器上快速跑完大量測試。Simulated throttling 的完整運作原理可以在 Lighthouse 官方 throttling 文件找到詳細說明。

網路參數：Slow 4G 預設代表什麼

Lighthouse mobile 預設的網路設定來自 Chrome UX Report (CrUX) 的第 25 百分位 4G 連線數據，大約等於「4G 連線中最慢的那 25%」。

完整網路參數：

CLI 參數	預設值	說明
--throttling.rttMs	150	RTT（往返延遲），單位 ms
--throttling.throughputKbps	1638.4	整體吞吐量，1.6 Mbps
--throttling.requestLatencyMs	562.5	每次請求加上的延遲
--throttling.downloadThroughputKbps	1474.56	下行頻寬
--throttling.uploadThroughputKbps	675	上行頻寬

這組參數對 LCP 的影響特別直接。一個 200KB 的 hero image，在 1.6Mbps 下需要約 1 秒才能完成下載，加上 150ms RTT，光是圖片就吃掉了 LCP budget 的很大一部分。這就是為什麼 LCP 優化和網路節流設定密不可分。

如果你的網站主要服務台灣本地用戶，且實際流量分析顯示大多數訪客都在 4G 以上，可以考慮調整節流參數到更接近實際使用場景，但要在報告中明確標注這不是標準測試條件。

切換到 Desktop 模式後，網路 RTT 降到 40ms、頻寬提升到 10Mbps，但 CPU 節流消失。這組參數更接近有線網路的家用電腦，分數通常比 mobile 高 20-40 分不罕見。

CPU 節流：4x 到底等於哪種手機

Lighthouse 的 CPU 4x 節流意思是：本來需要 10ms 完成的 JavaScript 任務，會被延長到 40ms。這不是假裝你的 CPU 是另一顆晶片，而是在執行過程中每隔一段時間中斷，讓它的有效執行速度變慢 4 倍。

4x 的設計目標是把「2022 年的高階開發者筆電」的效能，拉到「2022 年的 mid-tier Android 手機」的水準。但這裡有一個根本問題：4x 是相對你的機器的，不是絕對值。

Lighthouse 每次跑測試時都會計算一個 benchmarkIndex，用來記錄當次執行環境的 CPU 效能。這個數字會出現在報告的 Environment 欄位。

實際的對照關係大概是這樣：

你的機器等級	預設 4x 節流後等效於	建議調整
M2 MacBook Pro	還是比 mid-tier Android 快很多	調到 6-8x
M1 MacBook Air	介於 high-end 和 mid-tier 之間	調到 5-6x
Intel i7 筆電（2020）	接近 mid-tier Android	4x 大致合理
CI runner (GitHub Actions)	視 runner 而定，差異很大	固定 multiplier + 記錄 benchmarkIndex

Chrome Canary 有一個校準功能，可以自動根據你的機器計算建議 multiplier。根據 DebugBear 的 CPU throttling 分析，low-tier device 的 multiplier 是 14.7x，mid-tier 是 3.6x。注意 mid-tier 是 3.6x，比預設的 4x 還低，代表預設值對某些機器可能已經過度節流。你也可以用 Lighthouse CPU Throttling Calculator 輸入你的 benchmarkIndex 來計算適合的乘數。

M1/M2 Mac 的節流問題

這是最多工程師在 GitHub 上回報的問題之一（Issue #14228）。M1/M2 Mac 的 CPU 效能大幅超越 Intel 時代的假設，4x 節流後仍然比真實 mid-tier Android 快很多。

實際影響：同一個頁面，在 M2 MacBook 上用 4x 跑 Lighthouse，Performance 分數可能是 78；在 Intel i7 筆電上用相同設定跑，可能只有 65。差距不是小數，是會影響判斷的落差。

如果你想在 M1/M2 Mac 上取得更接近真實使用者體驗的分數，有幾個選項：

1. 手動調高 multiplier：改成 6x 或 8x，方法是在 DevTools Lighthouse 設定中切換到 DevTools throttling（不支援直接調整 simulated 的 multiplier），或用 CLI 的 --throttling.cpuSlowdownMultiplier=6
2. 用 WebPageTest：選擇你目標受眾實際使用的裝置（例如 Moto G4 或 Galaxy A51），在真實裝置上跑，不依賴模擬
3. 對照 CrUX 數據：不要只看 lab data，把 CrUX 查詢出來的 p75 field data 當主要判斷依據

在報告規範上，如果你的專案或 CI 系統需要跨機器比較分數，建議在每份報告中記錄 benchmarkIndex，過濾掉 benchmarkIndex 差異超過 20% 的比較。

Lighthouse 分數的「變好」和「變差」要有意義，前提是測試條件一致。機器換了但沒調整 multiplier，是最常見的誤判來源。

DevTools Throttling vs Simulated：怎麼選

這兩種方法不是互相取代的關係，它們各有適用場景。DebugBear 對 Simulated throttling 的分析指出，當 simulated 結果比 DevTools 測試更好時，通常代表模擬誤差而非真正的效能優勢。

比較項目	Simulated	DevTools	Packet-level
準確度	中（edge case 不準）	中高（request level）	高（TCP level）
測試速度	快	慢（需真實等待）	最慢
分數變異	低	中	高
CLI flag	--throttling-method=simulated	--throttling-method=devtools	需用 WebPageTest
對應工具	Lighthouse、PageSpeed Insights	Lighthouse CLI、DevTools	WebPageTest
能對照 Performance panel	無法	可以	可以
後端回應時間模擬	有限	有限	完整

用 DevTools throttling 的兩個主要理由：

1. 你需要對照 Performance panel：切到 DevTools throttling 後，Lighthouse 報告中顯示的時間軸，和你在 Performance 面板錄製的 trace 時間軸是一致的。這讓你可以從報告直接跳到 trace 找瓶頸，不會看到時間不對齊的困惑
2. 頁面有複雜第三方依賴：多個不同伺服器的資源、CDN 回應時間差異大，simulated 的簡化模型容易出問題，DevTools 的 request-level 延遲更接近真實

不適合用 DevTools throttling 的情況：CI 自動化測試。DevTools throttling 需要實際等待網路和 CPU，測試時間長，分數變異也比 simulated 高，不適合當 CI gate 的判斷基準。

Lighthouse 的 三種分析模式（Navigation、Timespan、Snapshot）在使用 DevTools throttling 時行為也略有不同，Timespan 模式下 CPU throttling 對分數的影響更敏感。

為什麼本地 Lighthouse 和 PageSpeed Insights 分數不一樣

這個問題幾乎每個剛開始優化 Core Web Vitals 的工程師都遇過：本地跑 Lighthouse 85 分，PageSpeed Insights 給 62 分，兩個都說用的是 simulated throttling，為什麼不一樣？

原因不是 throttling 方法不同，而是跑測試的機器效能不同。

PageSpeed Insights 在 Google 的伺服器上跑 Lighthouse，那些伺服器的 CPU 效能和你的 MacBook 不一樣。即使都套 4x 節流，基準效能的差異讓結果有落差。

benchmarkIndex 是用來量化這個差異的指標。Lighthouse 每次跑測試都會計算一個 benchmarkIndex 值，代表執行環境的 CPU 效能。Google 的測試環境通常跑出比一般開發者筆電更低的 benchmarkIndex，因此套上相同 4x 後，實際模擬出的「手機等級」也不一樣。

看 PageSpeed Insights 報告時，往下找「Environment」部分，確認 benchmarkIndex。如果你的本地 Lighthouse 報告 benchmarkIndex 是 1200，PageSpeed Insights 是 600，那麼分數的差距有一部分就是這 2 倍的執行環境差異造成的。

另一個常見原因：PageSpeed Insights 會同時跑 lab data（Lighthouse）和 field data（CrUX）。lab data 分數是 simulated，field data 是實際用戶數據。如果你的頁面有快取熱效應（return visitor 比例高），field data 往往比 lab data 好；反之如果有大量 JS 阻塞主線程的問題，field data 可能比 lab data 更差。

跨工具比較分數沒有意義，同一工具同一環境的前後比較才有意義。建議的做法是把 PageSpeed Insights 和本地分數的差異當成方向參考，不要花時間試圖讓兩個數字對齊。

CLI 完整節流設定指南

Lighthouse CLI 的節流設定共有兩個層次：用 --throttling-method 選擇 simulated、devtools 或 provided 三種方法之一，再用 --throttling.* 系列 flag 微調 RTT、頻寬和 CPU 乘數。最常用的組合是 --throttling-method=devtools --throttling.cpuSlowdownMultiplier=4，在 CI 環境中搭配 --output=json 輸出報告並記錄 benchmarkIndex，讓不同執行環境的結果可以被對比驗證。

選擇 Throttling 方法

# 預設，simulated throttling
lighthouse https://speedpark-koinoura.com --throttling-method=simulated

# DevTools throttling，更接近真實測試
lighthouse https://speedpark-koinoura.com --throttling-method=devtools

# 使用外部提供的節流（例如 WebPageTest 已設定好的環境）
lighthouse https://speedpark-koinoura.com --throttling-method=provided

每段 code 搭配說明：provided 方法適合在 WebPageTest 或其他已設定好網路條件的環境中使用，告訴 Lighthouse「別加自己的節流，測試環境已經有了」。

調整 CPU 乘數

# M1/M2 Mac 建議調高
lighthouse https://speedpark-koinoura.com \
  --throttling-method=devtools \
  --throttling.cpuSlowdownMultiplier=6

# 想模擬極低端設備
lighthouse https://speedpark-koinoura.com \
  --throttling.cpuSlowdownMultiplier=10

注意 --throttling.cpuSlowdownMultiplier 在 simulated 模式下仍然有效，但效果不如 DevTools throttling 直接，因為 simulated 是模型估算，不是真的 CPU 中斷。

自訂網路參數

# 模擬台灣 5G 環境（低延遲、高頻寬）
lighthouse https://speedpark-koinoura.com \
  --throttling.rttMs=20 \
  --throttling.downloadThroughputKbps=50000 \
  --throttling.uploadThroughputKbps=20000 \
  --throttling.cpuSlowdownMultiplier=1

# 模擬偏鄉 3G 環境
lighthouse https://speedpark-koinoura.com \
  --throttling.rttMs=400 \
  --throttling.downloadThroughputKbps=400 \
  --throttling.uploadThroughputKbps=200 \
  --throttling.cpuSlowdownMultiplier=6

自訂網路參數時，記得同步調整 --throttling-method=devtools，否則 simulated 模式會忽略部分自訂參數。

輸出報告並記錄 benchmarkIndex

lighthouse https://speedpark-koinoura.com \
  --output=json \
  --output-path=./report.json \
  --throttling-method=devtools \
  --throttling.cpuSlowdownMultiplier=4

# 從 JSON 提取 benchmarkIndex
node -e "
const r = require('./report.json');
console.log('benchmarkIndex:', r.environment?.benchmarkIndex);
console.log('LCP:', r.audits['largest-contentful-paint']?.numericValue, 'ms');
"

把 benchmarkIndex 記錄到測試 log 裡，之後比較分數時可以過濾掉環境差異造成的偽變化。

CI/CD 環境：如何讓 Lighthouse 節流結果可信

CI 環境的 Lighthouse 測試有一個經典問題：GitHub Actions 的 runner 效能不穩定，同一個 commit 可能因為 runner 負載不同跑出差距 10 分的結果。

讓 CI Lighthouse 可信的幾個做法：

固定 multiplier + 記錄 benchmarkIndex

# .github/workflows/lighthouse.yml 範例
- name: Run Lighthouse CI
  run: |
    npx lhci autorun \
      --config.settings.throttlingMethod=devtools \
      --config.settings.throttling.cpuSlowdownMultiplier=4 \
      --config.collect.numberOfRuns=3

跑三次取中位數。單次測試的結果在 CI 環境下變異太大，三次取中位數讓結果穩定很多。

在報告中記錄 benchmarkIndex

# 建立 lighthouserc.js
module.exports = {
  ci: {
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 0.7 }],
      },
    },
    collect: {
      numberOfRuns: 3,
      settings: {
        throttlingMethod: 'devtools',
        throttling: {
          cpuSlowdownMultiplier: 4,
        },
      },
    },
  },
};

加 numberOfRuns: 3 是必要的，不是可選的。CI runner 的 CPU 負載會在不同時間點有差，三次取中可以過濾掉尖峰值。

使用 dedicated runner 或 benchmarkIndex 過濾

如果預算允許，用 self-hosted runner 而不是 GitHub 的 shared runner。自己的 runner 效能固定，benchmarkIndex 穩定，分數的前後比較才有意義。

如果必須用 shared runner，可以在 CI 腳本中讀取 benchmarkIndex，當 benchmarkIndex 和歷史基準差超過 20% 時，標記該次結果為「環境異常」，不納入 performance budget 判斷。

效能預算和 CI Lighthouse gate 要能信任，節流設定的一致性是基礎。Core Web Vitals 是 Google 頁面體驗的評估信號，Lighthouse 提供的是 lab data 診斷結果，不是直接的排名分數；CI gate 失去可信度代表你的效能優化是否有效將無法被正確追蹤。

常見問題 FAQ

以下整理 Lighthouse 節流設定最常見的五個問題。核心答案是：分數浮動大通常來自 simulated throttling 的估算變異或機器 CPU 負載不穩；想要可靠結果，切到 DevTools throttling、跑三次取中位數、記錄 benchmarkIndex，是基本三步驟。

Lighthouse 分數每次跑都不一樣，差距很大，怎麼辦？

分數浮動大通常有三個原因：

1. Simulated throttling 的估算本身有變異：每次載入的原始數據略有不同，模型估算的結果也會不同。切到 DevTools throttling，重複跑三次取中位數
2. 機器 CPU 負載不穩定：其他程序搶 CPU 時，Lighthouse 測試結果會偏低。盡量在其他程序都關閉的情況下跑
3. 網路本身有波動：即使是 Simulated throttling，第一次的原始載入受實際網路影響。如果你的測試環境網路不穩，結果也會不穩

要不要關掉 Lighthouse 的節流設定？

可以，用 --throttling-method=provided，但結果只對在同樣環境下的對比測試有意義。如果你的目的是評估對普通手機用戶的實際效能，關掉節流的 Lighthouse 分數沒有參考價值。

PageSpeed Insights 分數和 CrUX 有什麼關係？

PageSpeed Insights 顯示兩種數據：上方是 CrUX 的 field data（真實用戶過去 28 天的 p75 數據），下方是 Lighthouse 的 lab data（simulated throttling 的模擬結果）。field data 反映真實用戶體驗，lab data 是測試工具的診斷結果。兩個目的不同，不要直接比較，詳細說明可以看 CrUX 數據查詢。

想讓 Lighthouse 節流設定更接近台灣用戶，怎麼調？

從 Google Analytics 或 CrUX 拉出你的用戶的網路和裝置分佈，找出 p75 的連線速度和裝置等級，對應調整 --throttling.rttMs、--throttling.downloadThroughputKbps 和 --throttling.cpuSlowdownMultiplier。但這樣的客製化設定只適合內部分析，不要拿來和公開的 PageSpeed Insights 標準比較。

Lighthouse CPU throttling 和 Chrome DevTools 的 CPU throttling 一樣嗎？

不一樣。Chrome DevTools Performance panel 的 CPU throttling（在 Performance 面板的設定裡）是讓整個瀏覽器的 CPU 變慢，是互動式除錯用的。Lighthouse 的 CPU throttling 是為了模擬特定設備等級的效能，套用方式和目的不同，不要混用。