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 平台响应能力方面的问题，以及在 INP 于 2024 年 3 月成为核心网页指标之前如何改进 INP，展现了他们坚定不移地致力于在 CMP 产品中提供最佳性能。
PubTech 为何重视性能？
与大多数 CMP 一样，PubConsent CMP 也会以第三方脚本的形式在网页上实现意见征求管理功能。减少 CMP 产品对性能（包括对响应速度）的影响对于确保成功集成 CMP 至关重要。
通过优先考虑性能并使 PubConsent CMP 脚本保持轻量化，网站所有者可以在整合有价值的意见征求管理功能的同时，确保用户体验质量达到一种微妙的平衡。
<ph type="x-smartling-placeholder">鉴于 CMP 提供的功能的重要性及其对效果的影响，PubTech 设定了以下目标：
- 最大限度地减少 PubConsent CMP 产品对 INP 的影响。
- 减少归因于 CMP 产品的冗长任务。
- 缩短总阻塞时间 (TBT)，否则可能会对网页的 INP 产生负面影响。
INP 的衡量方式
PubTech 使用 Chrome 开发者工具进行初始分析并手动诊断出缓慢的互动。通过该工作流程，PubTech 能够精确找出影响网页响应速度的具体问题。例如，如果用户点击 CMP 产品中的互动来接受所有 Cookie 并随后关闭 Cookie 意见征求对话框，便会导致一项耗时较长的任务，导致界面呈现更新延迟。如下图所示，界面在耗时较长的任务完成后，界面才会更新为显示对话框已关闭。
与接受所有 Cookie 的按钮一样，用于拒绝所有 Cookie 或自定义 Cookie 偏好设置的按钮都遵循 PubConsent CMP 架构中的相同工作流程。因此，本案例研究中详述的改进影响了 CMP 产品中的一系列用户互动。
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">这种延迟会导致在执行任务期间，从视觉上看出面板处于锁定状态。由于 INP 阻止了渲染更新的较长时间，因此对网页的 INP 产生了负面影响。
<ph type="x-smartling-placeholder">PubTech 如何针对按钮和链接优化 INP
为了改进 INP，我们在 PubConsent CMP 中采用了不同的收益策略。
产生高优先级任务
以下代码段中显示的 yieldToMainUiBlocking 方法旨在优化高优先级 JavaScript 任务，具体方法是通过 scheduler.yield（如果有）让出，但如果 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 界面）。
PubTech 如何通过渲染布局优化进一步减少 TBT
应用收益策略后，发现 CMP 的 INP 有显著提升。事实上，在显著缩短事件处理脚本的处理时长之后，就发现有机会对关闭界面操作的下一次绘制进行进一步的渲染。此操作最初设计用于从 DOM 中移除元素。这就带来了一些挑战，尤其是在具有大量 DOM 节点的网站上，会导致渲染工作量意外增加。
为了解决从 DOM 中移除元素所需的渲染工作量增加的问题，我们引入了一种解决方案，该团队称为“延迟去渲染”。如果采用这种方法，在用户同意将其隐藏后，系统会先对 CMP 意见征求对话框应用 display: none CSS 规则。然后，使用 requestIdleCallback 将与 CMP 对话框关联的 DOM 节点的移除移至浏览器处于空闲状态的较晚时间点。事实证明，这种方法比在用户关闭意见征求对话框时移除 DOM 节点快得多。
<ph type="x-smartling-placeholder">PubTech 如何通过改进 IAB TCF 库进一步降低 INP
在成功解决 CMP 的大部分响应问题后，我们在该平台的主要依赖项之一（TCF 库）中发现了进一步的改进机会。
此库中计算开销最大的组件是“构建字符串”以及“调度同意书”这些组件是 IAB TCF 库不可或缺的组成部分。专门针对 PubTech 的需求在单独的分支中对这些组件进行了以下优化：
- 将计算结果重复用于解码流程，该过程会针对需要读取用户同意情况的每个第三方回调执行。
- 避免并减少发布商限制编码流程（在用户表示同意后执行）中的不必要的循环。
这些优化措施中的第一项缩短了 CMP 在连接到 IAB TCF 库的每个第三方回调上所花的时间。第二个优化缩短了“构建字符串”产生的处理时长组件。事实上，经过这项优化后，用户每次表示同意后所执行的循环次数可减少多达 60%。
结果
在采用之前的收益策略和新的呈现布局优化措施后，CMP 的 INP 提升高达 65%。因此，PubConsent CMP 用户体验的响应速度得到了极大的提升，对于某些广告，通过优化广告请求的触发时机，可见度甚至能提高 1.5%。
除了这些改进之外，在 IAB 的 TCF 库方面，我们还发现，由于将由 TCF 引起的耗时任务减少多达 85%，受影响的客户在移动设备上的 INP 提高了多达 77%。这有助于显著降低在页面的整个生命周期内执行的每个第三方回调的开销。
使用 PubConsent CMP 后，通过 INP 的来源数量增加了 400% 以上，从移动设备上的 13% 上升到了 55%。得益于 PubTech SDK 的优化，一些客户的网页 INP 减少了一半以上（从 470 毫秒减少到 230 毫秒）。
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
总结
PubTech 的客户很快就认识到，我们的优化工作取得了积极的 INP 效果和业务指标结果，并考虑利用来自其客户的宝贵真实用户监控 (RUM) 数据，进一步提升 PubConsent CMP 的性能。这些数据密切跟踪回归和进步，推动 PubTech 的持续改进工作。
作为第三方，PubTech 还意识到，他们有机会大规模提高网站性能，提高响应速度，同时避免对业务 KPI 产生负面影响。实施这些改进永远不算晚！
特别感谢 PubTech 首席技术官 Luca Coppola 为这项创新工作提供支持，以及来自 Google 的 Jeremy Wagner、Michal Mocny 和 Rick Viscomi。