網站速度診斷實戰 | 用 Lighthouse CLI 從 55 分修到 84 分
AI 文章延伸
選擇平台後可直接帶入閱讀脈絡，快速整理重點、補齊盲點，並延伸到同站相關文章。
前陣子幫一個客戶的站做健檢，手機版 Performance 只有 55 分，首屏要等 13.8 秒才畫出第一個字。網站速度慢這件事，多數人卡住的地方不是「不知道慢」，而是打開網頁版工具看到一堆紅字之後，不知道要回去改哪一行。
先給趕時間的人一句結論：排查網站速度最有效的順序，是先處理擋住畫面的渲染阻塞資源，再處理沒壓縮的圖片，最後才輪到零碎的 CSS 與 JavaScript。多數網站慢在字型和圖片，不在主機。
這次的案例就是最典型的一種，而元凶只有一支 232KB 的 CSS。
Lighthouse CLI 是什麼？跟網頁版做網站速度測試差在哪
Lighthouse 是 Google 的網頁品質稽核工具，會針對一個網址跑出 Performance、Accessibility、Best Practices、SEO 四個面向的分數。大部分人第一次接觸它是在 Chrome 開發者工具的 Lighthouse 分頁，或是 PageSpeed Insights 網站。
GUI 版本好上手，但有兩個限制。第一，每次都要手動開瀏覽器、點按鈕、等它跑完，排不進自動化流程。第二，它只吐一份漂亮的網頁報告，裡面的數據抓不出來給程式處理。
Lighthouse CLI 是同一顆引擎的命令列版本，掃完會同時產出兩份東西：一份給人看的 HTML 報告，一份給程式解析的 JSON。JSON 這份才是關鍵，因為可以用 jq 或任何腳本，把「哪個資源在拖慢頁面、能省幾秒」精準撈出來。
| 比較 | 網頁版（PageSpeed / DevTools） | Lighthouse CLI |
|---|---|---|
| 操作方式 | 手動開瀏覽器、點按鈕 | 一行指令，可寫進腳本 |
| 輸出 | 只有網頁報告 | HTML 報告 ＋ 可解析的 JSON |
| 適合 | 快速看分數 | 掃完直接對應到程式碼修改 |
| 自動化 | 不行 | 可排進 CI 或定期監測 |
如果只是想知道幾分，網頁版就夠了，但要從「幾分」走到「改哪一行」，得靠 CLI 這條路。
安裝與掃描：從自己的電腦測試網站速度
有 Node.js 環境的話，安裝只要一行：
npm install -g lighthouse裝完確認版本，我們這次用的是 12.8.2：
lighthouse --version這裡有個常被問到的選擇：要從主機上掃 localhost，還是從自己的電腦掃公開網址？答案是後者。從自己的電腦掃公開網址，量到的是 DNS、CDN、主機回應、實際傳輸的每一個檔案，也就是真人上站的體驗；從主機掃 localhost 會少掉網路這一段，數字漂亮但不真實。
Google 排名主要看手機版，所以預設就跑 mobile：
lighthouse https://www.example.com \
--output=html --output=json \
--output-path=./report \
--form-factor=mobile --screenEmulation.mobile=true \
--chrome-flags="--headless"跑完會拿到 report.report.html 和 report.report.json 兩個檔。Lighthouse 只是像訪客一樣載入頁面，唯讀、不會改到網站，拿來掃正式站是安全的。
讀懂報告：問題出在載入還是執行
拿到 JSON 之後先看四個分數和幾個核心指標，這次掃出來長這樣：
Performance: 55
Accessibility: 91
Best Practices: 100
SEO: 100
First Contentful Paint: 13.8 s
Largest Contentful Paint: 17.4 s
Total Blocking Time: 0 ms
Cumulative Layout Shift: 0這組數字藏著很明確的線索。FCP 13.8 秒、LCP 17.4 秒都慢得離譜，但 TBT 是 0、CLS 也是 0。
TBT（Total Blocking Time）量的是 JavaScript 執行時卡住主執行緒的時間，它是 0，代表 JS 沒有問題；CLS（Cumulative Layout Shift）量的是版面有沒有亂跳，也是 0，代表排版很穩。既然執行和排版都沒事，瓶頸就落在「載入」：瀏覽器遲遲畫不出畫面，是在等某個檔案下載回來。
這一刀切下去，排查範圍立刻從整個網站縮到網路請求那一區。這也是我們在 WordPress 網站變慢？活用 WP-CLI 找出問題 那次健檢學到的同一件事：先分清楚問題在哪一層，再動手，不然只是亂換快取外掛。
定位元凶：一支 232KB 的 Google Fonts 擋住首屏
繼續解析 JSON 裡的 opportunities（改善機會）和伺服器回應時間，兩個關鍵數字跳出來：
- 伺服器回應時間：Root document 只花 80 ms
- Eliminate render-blocking resources：可省 12.2 s
主機回應只花 80 毫秒，完全沒問題。真正拖住首屏的是渲染阻塞資源，光這一項就吃掉 12.2 秒。再往下追是哪個檔案，答案很乾脆：
[232KB Stylesheet] https://fonts.googleapis.com/css2?family=Playfair+Display...&Noto+Serif+TC...&Noto+Sans+TC...
[194KB Image] .../mimiapp-xxx-1.jpg
[186KB Image] .../mimiapp-xxx-5.jpg一支 Google Fonts 的 CSS 就 232KB，後面還牽出一整串 80 到 120KB 的中文字型 woff2。前 15 大網路請求裡有 12 個是字型。這支 CSS 印在 <head> 是會阻塞渲染的，瀏覽器要先把它下載、解析完才肯畫第一個字，手機慢速網路下光這一步就好幾秒。
回頭看佈景主題的 functions.php，它一次載了三套字型、七種字重：Playfair Display 四種、Noto Serif TC 三種、Noto Sans TC 四種。中文字型每個字重都是 MB 級的大檔，載這麼多本來就會慢。
到這裡，網站速度慢的根因已經從「感覺很慢」變成「functions.php 第 45 行的字型載入方式有問題」。這就是我們用 Lighthouse CLI 做網站速度檢測的價值：它把模糊的體感，換成一個可以對應到某一行程式碼的具體問題。
三步修復，全部落在佈景主題
根因確定之後，修改全部集中在 functions.php，不用動任何外掛。
第一步，字型改成非阻塞載入
這是省最多的一步。原本字型 CSS 是同步載入、會擋住渲染，改成先 preload、載完再 onload 套用，首屏就不用等它。常見寫法是用 media='print' 的技巧讓瀏覽器不把它當關鍵資源，載完再切回 all：
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?..."
media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?..."></noscript><noscript> 那行是給關掉 JavaScript 的訪客的 fallback，確保他們還是看得到字型。同時補上 fonts.googleapis.com 的 preconnect，原本只 preconnect 了 fonts.gstatic.com，少了這個，光補上去就再省 0.34 秒：
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>第二步，砍掉沒用到的字重
載了七種字重，但 CSS 裡真的有引用的沒那麼多。動手砍之前一定要先確認，不然會砍到正在用的、畫面就爆了。做法是把佈景主題 CSS 裡每個 font-weight 撈出來，對應到最近的 font-family，就知道每套字型實際用了哪幾種。這次比對的結果是：
- Playfair Display：只用到 600、700，多載的 500 和斜體可砍
- Noto Serif TC：400、500、600、700 都有用，維持不動
- Noto Sans TC：只用到 400、700，多載的 300、500 可砍
砍掉的都是 CSS 沒引用的字重，所以視覺零變化，但字型 CSS 和後續要下載的 woff2 都瘦了一圈。
第三步，圖片轉 next-gen 格式
這步優先度較低，但值得做。報告裡那兩張首頁 jpg（194KB、186KB）沒有用 next-gen 格式，轉成 WebP 大約能再省 0.5 秒。WordPress 可以用外掛批次轉，或在上傳流程裡自動處理。
成果：Performance 從 55 分修到 84 分
清完快取，重跑一次 Lighthouse CLI 驗證，同一支網址、同樣 mobile，前後對照如下：
| 指標 | 修改前 | 修改後 | 變化 |
|---|---|---|---|
| Performance | 55 | 84 | +29 |
| First Contentful Paint | 13.8 s | 1.3 s | 快 91% |
| Largest Contentful Paint | 17.4 s | 4.3 s | 快 75% |
| Speed Index | 13.8 s | 2.2 s | 快 84% |
真正讓分數暴增的是第一步的字型非阻塞載入，首屏不用再等字型，FCP 直接從 13.8 秒掉到 1.3 秒。剩下 LCP 還有 4.3 秒的空間，瓶頸就在那兩張還沒轉 WebP 的首頁圖，這是下一輪要處理的。
另外要誠實提一個小代價：字型改用 swap 之後，CLS 從 0 微升到 0.054，那是字型切換造成的輕微位移，數值離 0.1 的門檻還有距離，這次先不處理。
順帶一提，速度修好不等於排名會跟著上去。Core Web Vitals 在 Google 的排名邏輯裡比較像是同分時的判準，結構層沒做對的網站，把速度衝到 100 分也補不回來，這部分我們在 為什麼 WordPress 對 SEO 友善？拆解 8 支 WordPress SEO 外掛的評分機制 裡拆得更細。
一套可以重複用的網站速度檢測流程
回頭看，這次做的事情就是同一套流程跑一遍，換到別的網站也適用：
- 掃描：用 Lighthouse CLI 掃公開網址，同時產出 HTML 和 JSON
- 判讀：看 TBT 和 CLS 是不是 0，先分清楚問題在「載入」還是「執行」
- 定位：從 JSON 的 render-blocking 和最大請求清單，找出具體是哪個檔案
- 對應：把那個檔案對回佈景主題或外掛的某一行程式碼
- 修復：字型非阻塞、砍字重、圖片 next-gen，由影響大到小
- 驗證：清掉 CDN 快取，重掃確認分數，別忘了快取這一層
網頁版工具能告訴你幾分，但要從幾分變成改哪一行，命令列吐出來的 JSON 才是真正好用的地方。如果問題不在前端載入，而是後台或資料庫變慢，那是另一條排查路線，我們在 WP-CLI 效能健檢那篇 記錄過完整過程，那次的瓶頸是外掛執行吃掉 67% 的載入時間，TTFB 從 4 秒降到 0.67 秒。
延伸思考
這篇文章的做法建立在幾個前提上，值得進一步思考：
- 這是一個「字型型」慢站：同一支 Lighthouse CLI 換個站會得到完全相反的結論，我們在 WP-CLI 那次健檢裡，瓶頸是外掛執行吃掉 67% 的載入時間，字型一點問題也沒有。可以移植的是判讀路徑（看 TBT、CLS、TTFB 三個數字），不是修復清單。
- Lighthouse 量的是實驗室數據：它模擬中階手機與節流網路，單次掃描本身就有幾分的浮動，和真實使用者的 CrUX 欄位資料不一定一致。分數適合當診斷工具，不適合當驗收標準，何況 84 分的站 LCP 還有 4.3 秒，離 2.5 秒的門檻仍有距離。
- 中文字型是這個案例的放大器：換成純英文站，同樣載七種字重的檔案量小一個數量級，同一個錯誤可能只造成 1 秒延遲。
其他領域也有類似的現象：
- 醫學的鑑別診斷：這次最有價值的兩個數字，其實是兩個「什麼都沒發生」的結果。TBT 0 和 CLS 0 一次排除掉 JavaScript 與版面兩整類病因，醫生縮小範圍靠的也是排除法，不是急著找到症狀。
- 專案管理的關鍵路徑法：我們並沒有刪掉那支 232KB 的 CSS，只是把它從關鍵路徑移到有浮時的位置，總工期就少了 12 秒。工作量一點都沒減少，順序換了而已。這也解釋了為什麼修完一輪還會有下一輪：瓶頸不會消失，它只會移動到下一個環節。
關鍵概念：關鍵渲染路徑、WordPress 效能最佳化、除錯排查方法論
常見問題
Lighthouse CLI 掃描會不會影響正在營運的網站？
不會。Lighthouse 只是像一般訪客一樣載入頁面，全程唯讀，不會寫入任何資料，也不會改動網站設定。唯一要留意的是流量很大的站在尖峰時段掃描會多產生一次頁面請求，避開尖峰即可。
手機版分數比電腦版低很多，是正常的嗎？
正常。Lighthouse 的 mobile 模式會模擬中階手機的 CPU 與 4G 網路，運算和頻寬都被刻意壓低，同一個網站分數落差 20 到 30 分很常見。因為 Google 以行動裝置優先建立索引，該以手機版分數為準。
沒有 Node.js 環境，可以只用 PageSpeed Insights 嗎？
可以，PageSpeed Insights 用的是同一顆引擎，分數與核心指標一致。差別在於它不給你可解析的 JSON，得手動從網頁報告一項一項看，較難把問題精準對應回程式碼，也沒辦法排進定期監測。
為什麼字型會比圖片更拖慢首屏？
因為印在 <head> 的字型 CSS 屬於渲染阻塞資源，瀏覽器必須先下載並解析完才會開始繪製畫面；圖片則可以邊載邊顯示，不會擋住整頁。中文字型檔案又特別大，一個字重動輒數百 KB 到 MB，載入多套多字重的成本遠比想像高。
網站也慢，但沒空一支檔案一支檔案追？歡迎聯絡我們，或加入我們的 LINE 官方帳號，我們可以用同一套 Lighthouse CLI 流程幫你診斷、實際改好程式碼，並交付修改前後的分數對照。
Google 偏好來源
喜歡我們的內容嗎？一鍵將我們設為偏好來源，未來在 Google 焦點新聞與 AI 概覽中就能優先看到我們的文章。