PubConsent CMP 如何通过使用浏览器的 Scheduler API 修复通过 Chrome 开发者工具发现的响应性问题，将客户的 INP 减少高达 64%。
意见征求管理平台 (CMP) 是一款工具，可通过在使用 Cookie 和跟踪技术之前征得用户同意，来帮助网站遵守隐私权法规。除了确保遵守法律法规的主要目标之外，作为第三方脚本的 CMP 还必须确保将对性能和用户体验的影响降到最低。
PubConsent CMP 是 PubTech 的最新产品。PubConsent CMP 以性能为重心，设计为轻量级，能够确保最佳的用户体验，并且对整体网站性能的影响微乎其微。
引入 Interaction to Next Paint (INP) 指标后，PubTech 得以发现 CMP 响应能力方面的问题。在本案例研究中，PubTech 介绍了他们如何在 PubConsent CMP 平台中解决响应性能方面的问题，以及他们如何在 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 方法旨在优化高优先级 JavaScript 任务，方法是通过生成 scheduler.yield（如果有），但在 postTask 可用时回退到 postTask 并使用 user-blocking（高）优先级，最后回退到什么状态。
这里避免了 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()（如果可用），但有所不同，具体区别在于：在非 Chromium 浏览器中使用中优先级 postTask，最后回退到 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 界面）。
PubTech 如何通过渲染布局优化进一步减少 TBT
应用收益策略后，我们发现 CMP 的 INP 有显著提升。事实上，在大幅缩短事件处理脚本的处理时长之后，我们发现了为 Close UI 操作的下一次绘制做出进一步渲染改进的机会。此操作最初旨在从 DOM 中移除元素。这带来了一些挑战，尤其是在具有大量 DOM 节点的网站上，会导致渲染工作量意外增加。
为了解决从 DOM 中移除元素所需的渲染工作量增加的问题，我们推出了一种名为“延迟去渲染”的解决方案。在用户同意隐藏该对话框后，此方法会先将 display: none CSS 规则应用于 CMP 意见征求对话框。然后，通过使用 requestIdleCallback，移除与 CMP 对话框关联的 DOM 节点会推迟到之后浏览器处于空闲状态的时间点。事实证明，相较于在用户关闭意见征求对话框时移除 DOM 节点，这种方法要快得多。
PubTech 如何通过改进 IAB TCF 库进一步降低了 INP
在成功解决 CMP 的大多数响应速度问题后，我们发现该平台的主要依赖性之一便是进一步改善机会：IAB 透明度和用户意见征求框架 (TCF) 库。
此库计算开销最大的组件是“构建字符串”和“分派同意”。这些组件是 IAB TCF 库不可或缺的一部分。针对这些组件的以下优化是在单独的分支中应用的，专门用于满足 PubTech 的需求：
- 重复使用解码过程的计算结果，该过程将对每个需要读取用户同意情况的第三方回调执行。
- 避免并减少了发布商限制编码过程中（会在用户表示同意后执行）中的不必要的循环。
其中的第一项优化缩短了 CMP 处理连接到 IAB TCF 库的每个第三方回调所用的时间。第二项优化缩短了“build 字符串”组件产生的处理时长。事实上，这种优化使每次用户表示同意时所执行的循环最多可减少 60%。
成果
在利用原有策略和新的渲染布局优化措施后，CMP 的 INP 提升了高达 65%。因此，PubConsent CMP 的用户体验得以大幅提升。此外，通过优化何时请求广告，某些广告的可见度甚至提高了 1.5%。
除了这些改进之外，IAB 的 TCF 库发现，由于 TCF 引起的耗时任务减少多达 85%，受影响的客户在移动设备上的 INP 提高了多达 77%。这有助于显著降低在网页的整个生命周期内执行的每个第三方回调的开销。
在使用 PubConsent CMP 时，通过 INP 的源站数量从 13% 提高到 55% 以上，增幅超过 400%。由于对 PubTech SDK 进行了优化，某些客户的网页 INP 减少了一半以上，从 470 毫秒减少到 230 毫秒。
总结
PubTech 的客户很快就认识到，我们的优化工作带来了积极的 INP 性能和业务指标成效，他们正在考虑充分利用来自客户的宝贵真实用户监控 (RUM) 数据来进一步提升 PubConsent CMP 的性能。此数据可密切跟踪回归和进步情况，推动 PubTech 的持续改进工作。
作为第三方，PubTech 还认识到他们有机会大规模提高 Web 性能，提高响应速度，同时避免对业务 KPI 产生负面影响。着手实施这类改进永远不嫌晚！
特别感谢 PubTech 首席技术官 Luca Coppola 为这项创新工作提供支持，同时感谢 Google 的 Jeremy Wagner、Michal Mocny 和 Rick Viscomi。