第三方外掛拖慢網站？追蹤碼的 INP/LCP 健檢與延遲載入指南
症狀：你的 INP 或 LCP 分數，是被什麼拖垮的？
當 PageSpeed Insights 或 GSC 的 Core Web Vitals 報告亮紅燈，特別是 INP (Interaction to Next Paint) 延遲或 LCP (Largest Contentful Paint) 載入過慢，首要嫌疑往往是第三方腳本——那些你為了分析、行銷或客服而嵌入的追蹤碼、廣告像素和聊天視窗。這些腳本在你不注意的時候累積，悄悄佔用主執行緒和網路資源，成為拖慢 Core Web Vitals 的常見元兇。如果你已經做過圖片壓縮、CSS 合併等基礎優化但分數仍未達標，那麼是時候將目光轉向這些外部程式碼了。
原因：台灣網站最常見的 5 種效能殺手腳本
並非所有第三方腳本影響都相同。根據實務經驗，對效能影響最大的通常依序是：1. 社交媒體像素與 SDK（Facebook Pixel, LINE Tag），2. 聊天機器人外掛，3. 影片嵌入（YouTube facade），4. A/B 測試與分析工具（如 Hotjar、Clarity），5. 廣告聯播網腳本。這些腳本之所以成為殺手，是因為它們常在頁面載入初期就發出同步請求，或持續執行高頻率的事件監聽（例如滑鼠移動追蹤），直接佔用瀏覽器最寶貴的主執行緒時間。
Facebook Pixel 與 LINE Tag 是台灣網站最普遍使用的轉換追蹤工具，但它們的腳本通常較為龐大，且需要在頁面載入早期執行以確保轉換事件能被準確記錄，因此容易阻塞主執行緒，影響 INP。聊天外掛如 Crisp 或 Tidio，除了載入自身的 JavaScript，還會插入 iframe 和建立多個網路連線，其複雜度對 INP 和 CLS 的影響都很顯著。YouTube 影片嵌入如果未經處理，會預先載入大量的播放器程式碼與相關資源，嚴重拖慢 LCP。即使是相對輕量的 Google Analytics 4 (gtag.js)，若配置不當（例如在所有頁面過早觸發），依然會產生可觀的阻塞時間。
檢測：如何用 DevTools 與 PageSpeed Insights 找出元兇
修復策略：defer、async 與 Facade 模式實戰
根據腳本類型選擇對策：非關鍵分析腳本（如某些 A/B 測試工具）可加上 `defer` 屬性，讓它在 HTML 解析完成後再執行；獨立運作且不依賴其他腳本的追蹤碼可使用 `async`；對於互動後才需要的腳本（如客服聊天視窗），最有效的方案是使用「Facade 模式」——先顯示一個外觀相似的靜態按鈕或圖片，只有當使用者點擊時，才真正載入該第三方服務的完整腳本與 iframe。
以台灣常見的聊天外掛為例，未優化時它可能在頁面載入時就拉取約 200KB 的資源。採用 Facade 模式後，初始載入時只載入一個幾 KB 的按鈕圖檔與點擊監聽器，將核心腳本載入延遲到使用者互動後，能將主執行緒的阻塞時間大幅降低，直接改善 INP。對於必須同步載入的關鍵腳本（如某些必要的基礎設施腳本），則應確保其本身是輕量級的，或嘗試使用 `async` 並嚴格監控其效能影響。Google 官方在 web.dev 的指南中也明確推薦對嵌入式內容（如影片、地圖、社群小工具）採用 Facade 模式。
驗證與管理：用 GTM 統一管理，並持續監控
優化後，務必回到 PageSpeed Insights 或 Lighthouse 重新檢測 INP/LCP 分數，確認改善效果。長期來看，建議將大部分第三方腳本透過 Google Tag Manager (GTM) 統一管理。GTM 的核心價值在於「治理」而非「魔法」，它能讓行銷人員無需每次修改程式碼，就能透過介面調整各個腳本的觸發條件，例如將熱圖工具的觸發點從「All Pages」改為「Window Loaded」，或將廣告轉換追蹤碼限制在僅於訂單感謝頁面觸發。
常見問題
如何判斷一個第三方腳本是否真的對我的網站有害？
關鍵不在腳本大小，而在其「阻塞時間」與「商業必要性」。使用 Chrome DevTools 的 Network 面板查看該腳本的 Blocking Time，並在 Coverage 面板檢查其程式碼實際使用率。同時，與行銷團隊確認該腳本目前是否仍在運行有效活動，一個無人使用但持續載入的腳本，就是應該優先移除的對象。
defer 和 async 到底有什麼區別？我該怎麼選？
兩者都是非同步載入腳本以避免阻塞 HTML 解析的屬性。主要差別在執行時機：`defer` 會在 HTML 完全解析後才執行，且保持腳本間的執行順序；`async` 則是腳本下載完畢後立即執行，不保證順序。因此，有依賴關係的腳本群應使用 `defer`，而像獨立的廣告追蹤碼這類互不依賴的腳本，可以使用 `async`。
Facade 模式具體要怎麼實作？聽起來很複雜？
實作起來並不複雜。以聊天工具為例，您可以先用純 HTML/CSS 或一個小圖檔製作一個外觀與真實聊天按鈕相同的「偽按鈕」放在頁面右下角，並為其添加點擊事件監聽器。當使用者點擊時，監聽器再動態插入真正聊天工具（如 Crisp）的初始化腳本與 HTML 元素。這樣一來，整個聊天外掛的重型腳本就被延遲到使用者互動之後載入。
使用 Google Tag Manager 就能自動優化所有腳本的速度嗎？
不，GTM 是治理工具，不是效能魔法。它能幫您集中管理並靈活設定各個腳本的觸發條件（例如延遲觸發、特定頁面觸發），這能有效減少不必要的全域載入。但是，GTM 容器本身也是一個需要載入的 JavaScript 檔案，而且如果所有 Tag 都設為「All Pages」立即觸發，效能問題依然存在。最佳實踐是利用 GTM 的靈活性，為每個腳本設定最符合其需求的觸發規則。
移除腳本後，GSC 裡的 Core Web Vitals 分數多久會更新？
GSC 與 PageSpeed Insights 的分數更新並非即時。移除腳本後，您可以在 PageSpeed Insights 使用新的 URL 測試立即看到實驗室數據的改善。但 GSC 的欄位資料（Field Data）是蒐集實際用戶瀏覽數據，通常需要等待數天至數週，系統才會累積足夠的新樣本。建議您在移除後持續監控 GSC 的 Core Web Vitals 報告，並以一段時間（例如兩週）的趨勢來判斷成效。
如果為了商業需求，某些高影響腳本（如 Facebook Pixel）必須在所有頁面載入，該怎麼辦？
在這種情況下，優化重點轉為「減輕其影響」。首先，確保您使用的是該工具最新、最優化的版本，並透過 GTM 或直接寫碼採用 `defer` 屬性。其次，檢查腳本初始化配置，關閉所有非必要的即時追蹤功能（例如滑鼠移動熱圖，如果不需要）。最後，可以考慮與該服務商確認是否有更輕量的「事件 API」模式，允許您延遲載入核心腳本，僅在必要時（如頁面互動後）才發送特定事件。