嘿～ 最近在一些群組看到不少人為了 Lighthouse 的分數很焦慮，好像分數不高，網站就會被 Google 丟到太平洋一樣 😂。你知道嗎，我剛開始也差不多，看到紅色就心慌，看到綠色就安心，超直覺的。
但老實說，玩久了就發現，Lighthouse 這東西，它更像一個健康檢查工具，而不是期末考。分數高低跟你「能不能上台大」沒有絕對關係，但紅字太多，肯定代表你的使用者正在受苦... Google 只是把這種「不爽的感覺」量化給你看而已。今天就來聊聊，咱們到底該怎麼看這份報告，特別是從 SEO 的角度，哪些才是真正該優先處理的重點。
先說結論：別再追一百分了，先搞懂這三件事！
與其追求那個虛幻的滿分，不如把力氣花在刀口上。我自己是覺得，對 SEO 影響最大、也最直接反映使用者體驗的，就是這三個指標：
- LCP (Largest Contentful Paint)：你的「門面」載入有多快？
- TBT (Total Blocking Time) / INP (Interaction to Next Paint)：網站看起來能用了，是真的能用嗎？
- CLS (Cumulative Layout Shift)：版面會不會亂跳，把使用者當猴子耍？
搞定這三樣，你的使用者體驗跟 SEO 基礎就穩了一大半。剩下的，很多時候是跟特定業務邏輯（例如追蹤碼、廣告）的必要之惡搏鬥，那又是另一個故事了。
檢測重點一：LCP - 你的第一印象真的及格嗎？
LCP，中文叫「最大內容繪製」，簡單講，就是使用者點進你的網站後，畫面上那個「最大的東西」花了多久才完全顯示出來。 這個「最大的東西」通常是首圖 (Hero Image)、大標題，或是影片封面。你想想，使用者進來等了三、四秒，主視覺還沒出來，是不是很讓人想直接關掉？
Google 建議 LCP 最好在 2.5 秒內完成。 超過 4 秒就是不及格。在 Lighthouse 報告裡，它會直接告訴你哪個元素是 LCP。找到它，問題就解決一半了！
常見病因與解法：
- 圖片太大： 這大概是最常見的原因。拜託，不要把 2MB 的原圖直接丟上來啊！用 Squoosh 或 TinyPNG 這類工具壓縮一下，或是改用 WebP、AVIF 這類新世代的圖片格式。
- 伺服器太慢： 如果你的主機反應慢（也就是 TTFB 分數很難看），那 LCP 肯定快不起來。 這時候可能要考慮升級主機方案，或用 CDN (內容傳遞網路) 來加速。
- 被其他資源卡住： 有時候不是圖片慢，而是被前面的 CSS 或 JavaScript 卡住了，輪不到它載入。這就是下一個我們要談的 TBT 問題。
檢測重點二：TBT / INP - 別讓你的網站成為「看起來能動」的假人
這組指標真的超重要，但也是最多人忽略的。TBT (總阻斷時間) 是 Lighthouse 報告裡的「實驗室數據」，它模擬的是網頁在載入時，主線程被「卡住」多久，導致使用者不能互動。 而 INP (下次互動までの描画) 則是 Google 在 2024 年正式用來取代 FID 的 Core Web Vital「現場數據」指標。
簡單比喻，你進到一家餐廳，菜單已經放到桌上 (FCP/LCP 完成了)，但你招手叫服務生，他卻一直忙著跟別人講話，完全不理你。這個「不理你」的時間，就是 TBT/INP 的核心概念。對使用者來說，這超級惱人！一個按鈕看起來可以按，結果按下去沒反應，這體驗超差的。
常見病因與解法：
- 萬惡的 JavaScript： 沒錯，99% 的 TBT/INP 問題都跟 JS 有關。特別是第三方的追蹤碼、聊天機器人、廣告腳本...它們最喜歡在主線程搞事。
- 解法思考： 與其說是「優化」，不如說是「取捨」。真的需要裝這麼多追蹤器嗎？聊天機器人能不能延遲載入 (Lazy Loading)？有些 JS 是不是可以拆分，等使用者需要時再載入？
檢測重點三：CLS - 別在使用者閱讀時玩「乾坤大挪移」
CLS，中文是「累計版面配置位移」，白話文就是「頁面亂跳的程度」。 你一定遇過這種情況：正要點擊一個按鈕，突然上面冒出一個廣告，結果你點到廣告；或是文章看一半，字體突然變換，整段文章都移位了... 超煩！
Google 對這個指標的容忍度很低，分數最好在 0.1 以下。 它直接反映了網站的穩定性和對使用者的尊重程度。 CLS 過高，通常都是一些小細節沒做好。
常見病因與解法：
- 沒給圖片尺寸： 這是頭號戰犯！圖片載入需要時間，如果你沒在 `
` 標籤或 CSS 裡先設定好寬高或 `aspect-ratio`，圖片載入完成後就會把下面的內容「擠下去」。
- 網路字型 (Web Fonts) 載入： 瀏覽器一開始會先用系統預設字體顯示文字，等你指定的華麗字型載好之後再替換掉，這「一換」就可能導致版面跳動。解法是使用 `font-display: swap;` 搭配預載入 (preload) 設定，盡量縮短這個空窗期。
- 動態插入的內容： 像是那些「接受 Cookie」的橫幅、或是後來才出現的廣告，如果沒有預留好空間，就會像空降部隊一樣把現有版面搞得一團亂。
實戰對照：診斷前後差在哪？
光說不練太空泛，我們來看看一個假想案例。假設有個網站，Lighthouse 報告慘不忍睹，我們針對上面三個重點動手腳，會發生什麼事？
| 診斷項目 | 優化前（工程師崩潰版 😭） | 優化後（使用者開心版 😄） |
|---|---|---|
| LCP (最大內容繪製) | 4.5s... 首頁那張 3MB 的 Banner 圖是元兇，伺服器還在地球另一端。 | 1.8s！圖片壓縮到 200KB，換成 WebP 格式，再掛上 CDN。咻一下就出來了！ |
| TBT / INP (互動延遲) | TBT 500ms... 裝了五個分析腳本、兩個廣告、一個客服外掛，頁面跟中風一樣。 | TBT 80ms。只留必要的 GTM，其他腳本全部延後執行，使用者終於可以順暢點擊了。 |
| CLS (版面位移) | 0.3... 圖片沒寫尺寸，字體載入也亂跳，使用者想點 A 最後都跑到 B。 | 0.05。所有圖片都加上 `aspect-ratio`，字型也做了預載，版面穩如泰山。 |
別只看 Lighthouse！搭配 PageSpeed Insights 服用效果更佳
最後想提醒一下，你在自己電腦上跑的 Lighthouse (也就是 Chrome DevTools 裡的那個)，是「實驗室數據」(Lab Data)。 它模擬的是在一個固定性能的手機和網路速度下的表現。 但你真正的使用者，網路環境跟手機型號五花八門。
所以，一定要去看看 Google 的 PageSpeed Insights。 它是同一個引擎，但它多了一個超重要的東西：「現場資料」(Field Data)，也就是來自「Chrome 使用者體驗報告 (CrUX)」的真實數據。 這些數據才是 Google 拿來當作排名參考的 Core Web Vitals。 很有趣的是，有時候你的 Lab Data 很漂亮，但 Field Data 卻很糟，這通常代表你的使用者主力，網路環境或設備比你想像的要差很多。反過來說，如果 Lab Data 不好，但 Field Data 還不錯，那或許你該慶幸你的客群網路都很快... 但還是要修啦！
這種 Lab 跟 Field data 的差異，在 Google 的官方文件 web.dev 上有很詳細的解釋。 但我發現，很多台灣的行銷或開發部落格比較少強調這點，常常只拿 Lighthouse 的分數來講。 其實兩者對照看，才能拼湊出網站效能的全貌。
好了，今天先聊到這。效能優化是個無底洞，但抓住重點、看對數據，至少不會瞎忙一場。那你呢？你的 Lighthouse 報告裡面，最讓你頭痛的是哪個紅字？在下面留言分享一下，一起取暖抱怨吧！😂
