PubConsent CMP 如何運用收益策略，使用瀏覽器的排程器 API，修正透過 Chrome 開發人員工具找出的回應速度問題，進而將客戶的 INP 減少最多 64%。
「同意聲明管理平台」(CMP) 這項工具可讓網站先取得使用者同意聲明，才能使用 Cookie 和追蹤技術，協助網站遵守隱私權法規。除了確保遵循法規的主要目標，CMP 也是第三方指令碼，也必須盡量減少對成效和使用者體驗的影響。
PubConsent CMP 是 PubTech 的最新產品。PubConsent CMP 的設計以效能為重心，具備輕量化設計，可確保最佳使用者體驗，將對網站整體效能的影響降到最低。
採用「與下一個繪製互動 (INP)」指標後，PubTech 得以找出 CMP 回應速度的問題。在本個案研究中，PubTech 顯示他們如何解決 PubConsent CMP 平台的回應速度問題，以及 INP 在 2024 年 3 月成為網站體驗核心指標之一之前，如何改善 INP，展現在 CMP 產品中盡可能提供最佳成效的承諾。
為什麼 PubTech 關心效能？
與大多數 CMP 一樣，PubConsent CMP 會提供同意聲明管理功能，並以第三方指令碼的形式導入網站網頁上。降低 CMP 服務 (包括回應速度) 的成效影響，是確保 CMP 整合成功的關鍵。
藉由優先提升成效，並將 PubConsent CMP 指令碼保持精簡，網站擁有者在整合重要的同意聲明管理功能的同時，可在維持使用者體驗品質的同時，取得巧妙平衡。
考量到 CMP 提供的功能的重要性 (以及對成效的影響)，PubTech 設定了下列目標：
- 盡量減少 PubConsent CMP 產品對 INP 的影響。
- 減少可歸因於 CMP 產品的長時間工作。
- 減少總封鎖時間 (TBT)，這可能會對網頁的 INP 造成負面影響。
INP 的評估方式
PubTech 使用 Chrome 開發人員工具進行初步分析，並手動診斷緩慢互動。透過這個工作流程，PubTech 能找出影響網頁回應速度的特定問題。舉例來說，在 CMP 產品中透過點擊互動接受所有 Cookie 後，關閉 Cookie 同意聲明對話方塊，導致長時間工作導致使用者介面算繪延遲。如下圖所示，使用者介面並未更新，導致對話方塊在長時間工作完成後才關閉。
就像接受所有 Cookie 的按鈕一樣，拒絕所有 Cookie 或自訂 Cookie 偏好設定的按鈕，全都遵循 PubConsent CMP 架構中的相同工作流程。因此，本個案研究中詳述的改善措施影響了 CMP 產品中的一系列使用者互動。
這種延遲導致面板在工作期間處於鎖定狀態。因為長時間封鎖了轉譯更新程序，導致網頁的 INP 受到負面影響。
PubTech 如何最佳化按鈕和連結的 INP
為改善 INP，PubConsent CMP 採用了不同的收益策略。
產生高優先順序任務
以下程式碼片段顯示的 yieldToMainUiBlocking 方法旨在利用 scheduler.yield (如有) 產生 scheduler.yield，藉此最佳化高優先順序的 JavaScript 工作，但如果 postTask 可用，則會改回使用 user-blocking (高) 的優先順序 postTask，最後再改回什麼。
這裡避免使用 setTimeout，因為 yieldToMainUiBlocking 方法的用途是處理內部 CMP 設定作業，以及產生時應保留這類優先順序的高優先順序工作。這「不代表」只有導入這些排程 API 的瀏覽器 (目前僅支援於撰寫時使用的 Chromium 瀏覽器) 才受益於本個案研究中詳述的改良功能。即便如此，在高優先順序的任務中，這個做法仍被視為可接受的漸進增強效果。
function yieldToMainUiBlocking () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
}
}
resolve(false);
});
};
輕鬆處理中等和背景任務
以下程式碼片段顯示的 yieldToMainBackground 方法用來細分優先順序為 user-visible (中) 或 background 的長時間工作。邏輯會實作 scheduler.yield() (如果有的話)，但差別在於使用 postTask 搭配中優先順序，最後在非 Chromium 瀏覽器中改回使用 setTimeout。
function yieldToMainBackground () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
}
}
setTimeout(() => { resolve(true) }, 0);
});
};
yieldToMainBackground 產生內容的方式，可讓瀏覽器更快算繪下一個畫面 (在本例中關閉 CMP UI)。PubTech 如何透過算繪版面配置最佳化功能，進一步減少 TBT
套用收益策略後，INP 大幅改善了同意聲明管理平台。事實上，大幅縮短事件處理常式的處理時間長度後，有機會進一步改善針對「Close UI」動作的下一次繪製，進行其他轉譯改善。此動作最初的設計是為了移除 DOM 中的元素。這可能會帶來許多挑戰，尤其是在含有大量 DOM 節點的網站上，導致轉譯工作意外增加。
為瞭解決從 DOM 移除元素所需要的轉譯工作量增加，我們導入了「延遲去轉譯」團隊解決方案。此方法會先在使用者同意隱藏 display: none CSS 規則後，對 CMP 同意聲明對話方塊套用。接著，使用 requestIdleCallback，在瀏覽器閒置期間，移除與 CMP 對話方塊相關聯的 DOM 節點。事實證明，比起在使用者關閉同意聲明對話方塊時移除 DOM 節點，這種方法能更快處理完畢。
PubTech 如何藉由改善 IAB 資訊公開和同意聲明架構程式庫，進一步減少 INP
成功解決 CMP 大部分的回應問題後，我們在其中一個主要依附元件 (IAB 資訊公開和同意聲明架構 (TCF) 程式庫) 中發現了更多改善空間。
這個程式庫中最昂貴的運算元件是「建構字串」和「調度同意聲明」。這些元件是 IAB 資訊公開和同意聲明架構程式庫的重要部分。為滿足 PubTech 的需求，我們透過獨立分支，針對這些元件套用下列最佳化作業：
- 在解碼程序中重複使用計算的結果，每個需要讀取使用者同意聲明的第三方回呼都會執行此結果。
- 避免並減少發布商限制編碼程序中的不必要的迴圈，因為在使用者提供同意聲明時才會執行。
第一項最佳化措施是，同意聲明管理平台大幅減少了每次第三方回呼會掛鉤至 IAB 資訊公開和同意聲明架構程式庫的時間。第二個最佳化方法則縮短了「建構字串」元件產生的處理時間。事實上，透過這項最佳化功能，每當使用者表示同意時，系統就會執行高達 60% 的迴圈。
結果
根據先前產生的策略和新的顯示版面配置最佳化設定，CMP 的 INP 改善幅度最高達 65%。結果，PubConsent CMP 的使用者體驗速度大幅提升。就部分廣告而言，在系統要求廣告請求的情況下進行最佳化，可視度甚至提高了 1.5%。
除了這些改善外，在 IAB 資訊公開和同意聲明架構程式庫中，我們發現INP 對受影響的客戶進行了高達 77% 的改善，這能使資訊公開和同意聲明架構減少了高達 85% 的長工作量。這個做法有助於大幅降低在網頁整個生命週期中執行的每個第三方回呼負擔。
使用 PubConsent CMP 時，傳送 INP 的來源數量改善超過 400% (在行動裝置上從 13% 提高到 55%)。對某些客戶來說，PubTech SDK 執行了最佳化作業，使得頁面 INP 減少了超過一半 (從 470 毫秒到 230 毫秒)。
結論
透過我們的最佳化工作，PubTech 的客戶正迅速肯定 INP 成效和業務指標成果良好，並參考了客戶的即時使用者監控 (RUM) 資料，改善 PubConsent CMP 的成效。這些資料密切追蹤迴歸和進展，協助 PubTech 持續改善工作。
做為第三方合作夥伴，PubTech 也意識到自己有機會大規模提升網站效能、改善回應速度，同時避免對業務 KPI 造成負面影響。這些改進措施永不嫌晚！
特別感謝發布商技術長 Luca Coppola，以及 Google 的 Jeremy Wagner、Michal Mocny 和 Rick Viscomi。