代碼和代碼管理工具的最佳做法

針對 Core Web Vitals 將代碼和代碼管理工具最佳化。

Katie Hempenius
Katie Hempenius
X
Barry Pollard

代碼是程式碼片段 通常是透過代碼管理工具插入網站中。 代碼最常用於行銷和分析。

不同網站對代碼和代碼管理工具的成效影響大不相同。 可用來比對代碼管理工具與信封：代碼管理工具會提供 至於要填入什麼物品和使用方式，則完全由您決定。

本文會討論最佳化代碼和代碼管理工具的技巧， 成效和 Web Vitals 指標雖然本文提及 Google 代碼管理工具， 探討的其中許多構想也適用於其他代碼管理工具。

對 Core Web Vitals 的影響

因為代碼管理工具通常運用了資源來快速載入網頁並保持回應靈敏度，因此可能間接影響 Core Web Vitals。頻寬可以用來下載網站的代碼管理工具 JavaScript，或是下載這類代碼的後續呼叫。主執行緒的 CPU 作業時間可以用來評估及執行在代碼管理工具和代碼中包含的 JavaScript。

在重要網頁載入時間期間，Largest Contentful Paint (LCP) 容易發生頻寬爭用情形。此外，封鎖主執行緒可能會延遲 LCP 轉譯時間。

累計版面配置位移 (CLS) 會受到影響，原因包括在首次轉譯前延遲載入重要資源，或是代碼管理工具在網頁中插入內容等。

與下一個顯示的內容互動 (INP) 容易發生在主執行緒上的 CPU 爭用情況，而且我們發現代碼管理工具的大小和 INP 分數偏低。

代碼類型

代碼對成效的影響會因代碼類型而異。一般而言，圖片 標記 (「像素」) 的成效最佳，其次是自訂範本。 最後是自訂 HTML 代碼供應商代碼會因其功能而異 允許。

不過請注意，標記使用方式可能會對成效 這種做法「像素」因為這個代碼的性質 類型會嚴格限制使用方式。自訂 HTML 代碼 效能永遠不佳，但由於它們的自由程度較高 但服務很容易遭到濫用，而且效果太壞。

考慮使用代碼時，請謹記規模： 單個標記可能沒關係，但如果有成千上萬或數百個標記 標記，

並非所有指令碼都應使用代碼管理工具載入

標記管理員通常不適合用來載入 導入即時視覺或功能性的使用者體驗， 例如餅乾通知、主頁橫幅或網站功能使用代碼管理工具 載入這些資源時，往往會延遲傳送。這對使用者來說是壞事 體驗，也能增加 LCP 和 CLS 等指標此外， 請注意，有些使用者會封鎖代碼管理工具使用代碼管理工具導入使用者體驗 功能可能會導致部分使用者的網站無法正常運作。

請謹慎使用自訂 HTML 代碼

自訂 HTML 標記 這個領域已行之有年，大多數網站 都大量使用自訂 HTML 標記可讓你自行輸入程式碼，但幾乎沒有限制 這個代碼的主要用途是在網頁中加入自訂的 <script> 元素。

自訂 HTML 標記的方式有很多種，使用方式也很多種 差異極大評估網站成效時，請留意 大多數工具都會將自訂 HTML 標記的成效影響歸因於標記 自動插入代碼，而不是代碼本身

在 Google 代碼管理工具中建立自訂代碼的螢幕截圖

自訂 HTML 標記可將元素插入相關頁面。行動 網頁插入元素可能會引起效能問題 在某些情況下，也會導致版面配置位移。

  • 在大部分的情況下，如果網頁中插入元素，瀏覽器 必須重新計算網頁上每個項目的大小和位置，這項程序 稱為 版面配置。 單一版面配置對效能的影響微乎其微，但出現這種情況時 太過久可能成為效能問題的來源。這個問題的影響 在低階裝置和網頁 DOM 元素
  • 如果顯示在 DOM 中的可見網頁元素 區域經過轉譯後，可能會導致版面配置位移。這段現象 不是代碼管理工具獨有的功能，因為代碼通常會在稍後載入 而非網頁的其他部分，經常會插入網頁中的 DOM 算繪完成後，
，瞭解如何調查及移除這項存取權。

考慮使用自訂範本

自訂範本支援 某些作業與自訂 HTML 代碼相同，但必須以沙箱模式建立 為此，我們推出了 SDK 版本 常見用途的 API 例如指令碼插入和像素插入等顧名思義， 並由進階使用者建立範本 。較少技術人員可使用範本。這通常比較安全 而不需要提供完整的自訂 HTML 存取權

由於自訂範本的限制較高，因此這些標記 效能或安全性問題的可能性較低；不過 原因是自訂範本不適用於部分用途。

在 Google 代碼管理工具中使用自訂範本的螢幕截圖

正確插入指令碼

使用代碼管理工具插入指令碼是很常見的情形。 建議您使用自訂範本 injectScript敬上 也能使用 Google Cloud CLI 或 Compute Engine API

進一步瞭解如何使用 injectScript API 轉換現有的自訂 HTML 代碼，請參閱轉換現有的 標記。

如果您必須使用自訂 HTML 標記，請注意以下事項：

  • 程式庫和大型第三方指令碼應透過指令碼標記載入 下載外部檔案 (例如 <script src="external-scripts.js">)，而不是直接複製貼上指令碼的 複製到標記中雖然強制使用 <script> 標記 此功能會刪除獨立的往返作業，以便下載指令碼內容， 練習會增加容器大小，並防止系統快取指令碼 分別由瀏覽器建立
  • 許多供應商建議將自家的 <script> 代碼放在 <head>。不過，如果是透過代碼管理工具載入的指令碼，則建議使用 這通常是不必要的：在大部分的情況下，瀏覽器已經完成 在代碼管理工具執行期間剖析 <head>。

使用像素

在某些情況下，可以用圖片或 iframe 取代第三方指令碼 「pixels」相較於指令碼型的對應語言，像素可支援 反而通常會被視為較不偏好的實作方式，因為 我們接著介紹然而，在代碼管理工具中使用時，像素大小通常會有變化 因為這類事件可在觸發觸發條件時觸發，並傳遞不同的變數這些是 這個代碼類型較為安全且安全，因為在這之後就無需執行 JavaScript 就會觸發該執行緒Pixel 的資源大小非常小 (小於 1 KB)， 不會導致版面配置位移

請與您的第三方供應商聯絡，進一步瞭解他們是否支援 像素。此外，您可以嘗試檢查程式碼的程式碼是否具有 <noscript> 標記。 如果供應商支援像素，通常會將像素包含在 <noscript> 標記。

Google 代碼管理工具中的自訂圖片代碼螢幕截圖

像素的替代方案

當時 Pixel 最便宜的機型之一， 是最可靠的方式發出 HTTP 要求 回應不相關 (例如傳送資料給 Analytics 時) 提供者)。 navigator.sendBeacon()敬上 和 fetch() keepalive API 的設計也能因應相同的用途，但更加可靠 而不是像素。

繼續使用像素沒有任何問題，因為像素受到充分支援，且 將對效能的影響降到最低。不過，如果你要自行建構信標 建議您考慮使用其中一種 API

sendBeacon()

navigator.sendBeacon()敬上 API 適合用於將少量資料傳送至網路伺服器。 則伺服器回應不具任何影響。

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() 的 API 有限，僅支援提出 POST 要求，而且能 不支援設定自訂標頭。是 支援。

fetch() keepalive

keepalive敬上 允許 API： 可用來提出非封鎖式請求，例如事件報表和數據分析是 ，在傳遞至 fetch() 的參數中加入 keepalive: true。

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

如果 fetch() keepalive 和 sendBeacon() 看起來很相似，表示其 但實際上事實上，在 Chromium 瀏覽器中，sendBeacon() 現在是以 fetch() keepalive 為基礎建構而成。

選擇 fetch() keepalive 或 sendBeacon() 時，請務必 請考慮您需要的功能與瀏覽器支援。fetch() API 是 更具彈性；但 keepalive 的瀏覽器較少 支援，完全sendBeacon()。

取得說明

代碼通常是按照第三方供應商提供的指引建立。 如果不清楚供應商的程式碼用途，不妨詢問知道產品的人。 獲取第二項意見有助於判斷標記是否可能產生 效能或安全性問題

同時建議你在代碼管理工具中加上擁有者標籤。距離很遠 也很容易忘記擁有者是誰，並勇於移除標籤，以防萬一！

觸發條件

大致來說，最佳化代碼 觸發條件 通常包括避免觸發不必要的代碼 選擇能在業務需求和效能成本之間取得平衡的觸發條件。

觸發條件本身是 JavaScript 程式碼，會使程式碼的大小增加，然後執行 費用雖然大多數觸發條件都很小，但累積效果可以 。包含多次點擊事件或計時器觸發事件可能會大幅 增加代碼管理工具的工作負載

選擇適當的觸發事件

標記對效能的影響並不固定：一般來說 代碼觸發時，對成效的影響越大。資源通常屬於 因此在初始載入網頁時受到限制，因此載入或執行 和標記等資源

雖然請務必為所有代碼選擇適當的觸發條件，但這是 對載入大型資源或長時間執行的標記特別重要 指令碼

標記可在下列位置觸發： 網頁瀏覽 (通常是 Page load，發生時間為 DOM Ready、Window Loaded)，或根據 自訂事件如要避免影響網頁載入，建議觸發 Window Loaded 之後非必要的標記。

使用自訂事件

自訂事件 可讓您觸發觸發條件，以回應不在涵蓋範圍內的網頁事件 Google 代碼管理工具內建觸發條件。舉例來說，許多代碼都會使用網頁瀏覽 觸發條件；不過 DOM Ready 和 Window Loaded 之間的時間範圍可能相當長 可能會導致代碼觸發時難以微調自訂 事件，就能解決這個問題。

如要使用自訂事件，請先建立自訂事件觸發條件，並更新代碼 使用這個觸發條件

Google 代碼管理工具中的自訂事件觸發條件螢幕截圖

如要啟動觸發條件，請將對應的事件推送至資料層。

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

使用特定觸發條件

使用特定觸發條件可避免代碼在不必要的情況下觸發。 雖然運用這個概念的方法有很多種，但最簡單且最容易瞭解的方法之一 最實用的做法，是確保代碼只在其所在的網頁上觸發 實際用量

螢幕截圖：顯示 Google 代碼管理工具中的觸發條件

內建變數可以 也會納入觸發條件中，藉此限制代碼觸發。

不過請注意，設定複雜的觸發條件或例外狀況會 因此請勿過度簡化

在適當時機載入代碼管理工具

在代碼管理工具本身載入時調整設定，可能會大幅影響 才需進行無論觸發條件的設定方式為何，都無法觸發，直到 代碼管理工具載入後雖然您一定要為 個別代碼 (如上文所述)，可在載入代碼時進行實驗 因此，他們往往會得到等同或更大的影響 都會影響網頁上所有代碼

如果日後載入代碼管理工具，還會增加一層控制權，避免日後載入 成效問題，因為這會導致代碼管理工具使用者 不慎載入 標記過早，但沒有發現相關影響

變數

變數可讓網頁讀取資料。對觸發條件相當實用 標記本身

就像觸發條件一樣，變數會導致 JavaScript 程式碼加進代碼管理工具 以免造成效能問題變數可以是相對簡單的內建項目 可以讀取部分網址、Cookie、資料層或 DOM 的類型。 或者，它們也可以是完全無限制的自訂 JavaScript。

變數應力求簡單明瞭，因為這需要評估變數 由代碼管理工具持續運作移除不再使用的舊變數 縮減代碼管理工具指令碼的大小 使用方式。

標記管理

有效使用標記可降低成效問題的風險。

使用資料層

資料層「包含」 也就是要傳送給 Google 代碼管理工具的所有資訊」更多內容 確切來說，這是一個物件的 JavaScript 陣列，包含 該網頁。這些代碼也可用來觸發代碼。

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

雖然可以在沒有資料層的情況下使用 Google 代碼管理工具，但其使用方式是 我們強烈建議使用資料層可讓您整合資料 可讓第三方指令碼在同一處存取 更全面地掌握用量這有助於減少 多餘的變數計算和指令碼執行。您也可以透過資料層 控制標記所存取的資料，而不是提供完整的 JavaScript 變數或 DOM 存取

移除重複和未使用的標記

如果網頁的 HTML 標記中包含標記，可能就會發生標記重複的情形 除了透過代碼管理工具插入

您應暫停或移除未使用的代碼，而不是透過 觸發例外狀況。 暫停或移除代碼會從容器中移除程式碼；封鎖是 而不是

移除未使用的代碼時，觸發條件和變數也應如此 並確認是否可以移除任何僅供上述系統使用的應用程式 標記內。

使用允許和拒絕清單

允許和拒絕清單 可讓你針對代碼、觸發條件和 即可。這可用來確保效能達到最佳狀態 做法和其他政策

允許和拒絕清單是透過資料層設定。

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

舉例來說，您可以不允許任何自訂 HTML 代碼、JavaScript 變數或直接存取 DOM。只有像素和預先定義代碼 可與資料層中的資料搭配使用雖然規定相當嚴格 這有助於提高代碼管理工具導入作業的成效和安全性。

考慮使用伺服器端代碼

改用伺服器端代碼並不容易，但還是值得 尤其適合希望進一步掌控 資料。伺服器端代碼會將供應商程式碼從用戶端移除，並透過該代碼 將處理程序從用戶端卸載至伺服器

例如，使用用戶端代碼時，將資料傳送至多項 Analytics 帳戶是由用戶端針對每個端點發出個別的要求。 相較之下，使用伺服器端代碼則是由用戶端發出單一要求， 然後將這些資料轉送至不同的 Analytics 帳戶

請注意，伺服器端代碼僅適用於部分代碼。標記 相容性則因供應商而異。

詳情請參閱伺服器端簡介 標記。

容器

代碼管理工具通常會允許多個執行個體或「容器」影響 設定。這樣一來，一個代碼就能控制多個容器 管理員帳戶

每個網頁僅使用一個容器

使用多個 容器 單一頁面可能會產生重大效能問題 額外負擔和執行指令碼至少會重複複製 這會隨著容器 JavaScript，不能在容器之間重複使用。

有效使用多個容器的情況很少見。不過， 以下情況中：

  • 較輕的「早期載入」而「稍後載入」較為嚴重容器 而非單一大型容器
  • 具備受限的容器，不需要技術程度較低的使用者使用， 受限制但更嚴密控制的代碼容器 受限容器內的物件

如果每個網頁必須使用多個容器，請追蹤 Google 代碼管理工具的後續情況 設定多個 VM 的 容器。

視需要使用獨立的容器

如果您為多項資源 (例如網頁應用程式和 行動應用程式) - 您使用的容器數量可改善或損害工作流程 工作效率。這也會影響效能。

一般來說，單一容器可有效運用於多個 網站的使用方式和結構相似。舉例來說 行動版和網頁應用程式可提供類似的功能 應用程式的結構會不同，因此應用程式的管理方式 透過獨立的容器 讀取或部署個別容器

重複使用單一容器時，通常無謂地增加 強制採用複雜的邏輯，藉此降低容器的複雜度和大小 管理代碼和觸發條件

留意容器大小

容器的大小取決於代碼、觸發條件和變數。 雖然小型容器仍然可能不利於網頁效能 幾乎可以用

最佳化代碼時，容器大小不應是北星級指標 ；但大型容器大小通常是警告 未妥善維護且可能遭到濫用

Google 代碼管理工具 limits 容器 大小為 200 KB，且容器大小將從 140 KB 開始發出警告。不過 大多數網站都應將容器維持在小一點。適用對象 平均而言，網站容器大小約為 50 KB。

如要判斷容器大小，請查看回應的大小 由 https://www.googletagmanager.com/gtag/js?id=YOUR_ID 傳回。這個 回應中包含 Google 代碼管理工具程式庫，再加上 都會在 Docker 容器中執行Google 代碼管理工具的程式庫約為 33 KB 壓縮後的版本。

為容器版本命名

容器 版本 是容器內容在特定時間點的快照。使用 有意義的名稱，並加上簡短描述 大幅修改有助於日後對成效進行偵錯 以負載平衡機制分配流量 即可降低應用程式發生效能問題的風險

代碼工作流程

管理代碼變更相當重要，確保代碼沒有 可能會對網頁效能造成負面影響。

部署前先測試代碼

在部署前測試代碼，有助於找出問題 (成效且 否則商品在出貨前)。

測試代碼時的注意事項包括：

  • 代碼是否正常運作？
  • 這個標記是否會導致版面配置位移？
  • 代碼是否載入任何資源？這些資源有多大？
  • 代碼是否會觸發長時間執行的指令碼？

預覽模式

預覽模式 這樣就能在實際網站上測試代碼變更，而不必將變更部署到 公開發布。預覽模式內含偵錯控制台 標記的相關資訊

Google 代碼管理工具的執行時間可能不同 (稍慢) 在預覽模式下執行時，可能會需要額外負擔 輸入偵錯控制台中的資訊因此，您可以比較 Web Vitals 指標的評估結果 我們不建議您在預覽模式下收集到正式環境收集的資料。 不過，這項差異應該不會影響廣告代碼的執行行為 所發出的呼叫頻率

獨立測試

另一種測試代碼的方法是設立一個包含 並加入單一代碼 (您要測試的代碼) 的容器。這項測試設定較少 逼真且不會出現一些問題 (例如標記是否造成版面配置 轉換工具)，但還能更輕鬆地區隔並評估 標記執行方式看看 Telegraph 如何運用這個做法 隔離方式 效能 第三方程式碼

監控代碼成效

Google 代碼管理工具監控功能 API 收集執行作業的 時間 特定標記的個別值此資訊會回報給

詳情請參閱「如何建立 Google 代碼管理工具 監控

需要核准容器變更

第一方程式碼通常會先經過審查及測試再部署： 代碼一視同仁新增兩個步驟 驗證 但這項更新需要管理員核准才能容器變更 而負責任的 AI 技術做法 有助於達成這項目標或者，如果您不想要求兩步驟驗證 如果想要隨時掌握變更，您可以設定容器 通知 接收有關所選容器事件的電子郵件快訊。

定期稽核代碼使用情形

使用代碼的其中一項挑戰是，代碼往往會累積大量 time: 加入標記後，在極少的情況下會移除標記。定期稽核標記 如何反轉此趨勢理想的追蹤頻率取決於使用者 網站的代碼經常更新

為每個標記加上標籤，方便擁有者辨識 回應，可指出該代碼是否仍需要。

稽核代碼時，請務必清除觸發條件和變數 這類問題也很容易造成效能問題。

詳情請參閱將第三方指令碼放在下方 控管。