第三方追蹤腳本拖慢互動：defer 與 async 標籤盤點

作者：平白設計編輯部｜發布與最後查證：2026-09-29｜適用：台灣（中華民國）｜技術資訊，不保證搜尋排名

開學季過後，行銷團隊常會加入新的 LINE 客服外掛或熱點圖工具。這些第三方腳本若直接塞在 head 且未加延遲屬性，預設同步載入會阻塞主執行緒，拉長總阻塞時間。本文盤點外部腳本的載入策略，說明 defer 與 async 差異，並提供將非關鍵程式移至閒置時執行的具體做法。這屬於技術檢查，不保證 PageSpeed 分數或搜尋排名。

文章重點

• 第三方腳本預設同步載入會阻塞主執行緒，拉長互動延遲。
• TBT 是 Core Web Vitals 中反映主執行緒被佔用的關鍵指標。
• defer 依序在解析後執行，async 下載完立即執行，兩者適用情境不同。
• 非首屏必要腳本可改用 defer 或透過 Intersection Observer 動態載入。

開學季新增腳本為何拖慢網頁

開學一個月後，行銷團隊通常會急著上線新的 LINE 客服外掛、熱點圖工具或問卷彈窗。這些第三方腳本多半要求你把一段 script 標籤貼進 head，而且預設沒有加上任何延遲屬性。瀏覽器遇到這種同步腳本時，會暫停 HTML 解析，先下載並執行它，導致後續內容全部卡住。

當多個外掛同時採用同步載入，主執行緒就會被反覆佔用。使用者點擊按鈕或捲動頁面時，瀏覽器還在忙著跑分析代碼，畫面看起來沒反應。這種情況在行動裝置上特別明顯，因為手機的處理器效能有限，阻塞時間會被進一步放大。

要確認問題源頭，可以打開 Chrome DevTools 的 Performance 面板，觀察 Long Tasks 是否集中在第三方網域。另外，跑一次 Lighthouse 報告，查看「減少第三方程式碼影響」段落，就能列出哪些外部腳本吃掉最多主執行緒時間。

TBT 與互動延遲的關係

Total Blocking Time（TBT）指的是首次內容繪製到可互動時間之間，所有長任務超過五十毫秒的部分總和。簡單說，就是主執行緒被卡住、無法回應使用者操作的累計時間。這個指標直接對應到使用者感受到的「卡頓」。

在 Core Web Vitals 體系裡，TBT 雖然是實驗室指標，卻能有效預測實際互動體驗。第三方腳本是 TBT 飆高的常見元兇，因為它們往往包含大量初始化邏輯，例如建立 WebSocket 連線或掃描 DOM 結構，這些動作都需要佔用主執行緒。

降低 TBT 的核心思路不是刪除功能，而是把非必要的執行時機往後挪。就像網站改版後需要檢查基礎設定一樣，你可以參考改版後 favicon 路徑怎麼抽樣的做法，逐一盤點每個資源的載入優先順序，確保關鍵內容先呈現。

<script src="https://example.com/chatbot.js" defer></script>
<script src="https://example.com/analytics.js" async></script>
<script>
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const s = document.createElement('script');
      s.src = 'https://example.com/heavy-widget.js';
      document.body.appendChild(s);
      observer.disconnect();
    }
  });
});
observer.observe(document.getElementById('trigger-zone'));
</script>

defer 與 async 的差異與選擇

script 標籤的 defer 屬性會讓瀏覽器在背景平行下載檔案，但等到 HTML 解析完成後才依序執行。這表示多個 defer 腳本會按照它們在文件中的出現順序跑，不會互相搶佔執行緒，適合有依賴關係的程式庫。

async 屬性同樣允許背景下載，但一旦下載完成就立刻插入執行緒執行，不管 HTML 解析到哪了。多個 async 腳本的執行順序無法預測，因此只適合彼此獨立、不依賴 DOM 完整性的追蹤代碼或統計像素。

選擇原則很明確：如果腳本需要操作 DOM 或有先後依賴，用 defer；如果是純資料回報、跟畫面無關的獨立分析工具，用 async。兩者都比預設的同步載入好，能避免阻塞 HTML 解析，讓首屏內容更快顯示出來。

用 Intersection Observer 延後載入

即使加了 defer，某些重量級外掛（如聊天機器人視窗）仍會在頁面載入完畢後立刻執行，擠壓其他互動任務。更好的做法是根本不在初始 HTML 裡引入它，而是等使用者真正需要時才動態載入，把主執行緒的空檔留給核心內容。

Intersection Observer API 可以監聽特定元素是否進入可視範圍。例如把觸發按鈕放在頁尾，當使用者往下捲動接近該區域時，才透過 JavaScript 動態建立 script 標籤並插入聊天機器人的來源網址。這樣首屏的 TBT 幾乎不受影響。

這種按需載入的策略也適用於嵌入式影片、社群貼文牆或地圖元件。實作時記得搭配 fallback，確保網路較慢的使用者仍能手動點擊載入。順帶一提，檢查第三方嵌入是否影響中繼資料時，可參閱改版後 og:locale 怎麼抽樣的流程來驗證。

標籤管理工具的順序控制

許多公司使用 GTM 或其他標籤管理工具集中派發第三方腳本。這類平台本身提供了觸發條件設定，可以讓你在「視窗載入完成後」或「閒置時」才啟動特定標籤，而不必手動改寫每一段程式碼，大幅降低維護成本。

在標籤管理工具裡，建議把分析類追蹤碼設為非同步觸發，並限制其執行優先級。對於需要操作畫面的外掛，則安排在主要內容渲染完畢後再依序啟動。這樣既能滿足行銷需求，又不會讓所有腳本在同一瞬間爭搶主執行緒。

定期審查已安裝的標籤清單同樣重要。過期的活動追蹤碼或已停用的 A/B 測試工具若未移除，仍會消耗效能。每次改版或季度檢視時，應像核對改版後 web manifest 怎麼抽樣那樣，逐項確認每個外部腳本是否仍有存在必要。

常見問題

defer 和 async 哪個對 SEO 比較好？

兩者都能改善載入效能，但選擇取決於腳本特性。需要操作 DOM 的用 defer，獨立追蹤碼用 async。重點是避免同步阻塞，而非追求單一屬性的排名優勢。

Lighthouse 裡的 TBT 數據代表什麼？

TBT 是總阻塞時間，反映主執行緒被長任務佔用的累計毫秒數。數值越高，使用者點擊或捲動時感受到延遲的機率越大，是評估互動體驗的重要實驗室指標。

聊天機器人一定要一進頁面就載入嗎？

不一定。若機器人按鈕在頁尾，可用 Intersection Observer 等使用者捲動到附近才動態載入腳本，這樣能顯著降低首屏的 TBT，同時不影響功能使用。

用了 GTM 還需要手動加 defer 嗎？

GTM 容器本身建議用適當方式載入，而容器內的個別標籤則透過平台的觸發條件來控制時機，不需要也不建議手動在每個標籤上加 HTML 屬性。

重點摘要

1. 第三方腳本同步載入會阻塞主執行緒，拉長 TBT。
2. defer 適合有依賴的腳本，async 適合獨立追蹤碼。
3. 非首屏元件可改用 Intersection Observer 動態載入。
4. 定期清理標籤管理工具中過期或冗餘的外部腳本。

延伸閱讀

• 改版後 favicon 路徑怎麼抽樣
• 改版後 og:locale 怎麼抽樣
• 改版後 web manifest 怎麼抽樣