PubTech 的意见征求管理平台如何将客户网站上的 INP 降低多达 64%，同时将广告可见度提高多达 1.5%

PubConsent CMP 如何通过一种收益策略（使用浏览器的 Scheduler API 来修复使用 Chrome 开发者工具发现的响应问题）将其客户的 INP 降低高达 64%。

Marco Prontera

Gilberto Cocchi

意见征求管理平台 (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 脚本保持轻量化，网站所有者可以在整合有价值的意见征求管理功能的同时，确保用户体验质量达到一种微妙的平衡。

鉴于 CMP 提供的功能的重要性及其对效果的影响，PubTech 设定了以下目标：

最大限度地减少 PubConsent CMP 产品对 INP 的影响。
减少归因于 CMP 产品的冗长任务。
缩短总阻塞时间 (TBT)，这可能会对网页的 INP 产生负面影响。

INP 的衡量方式

PubTech 使用 Chrome 开发者工具进行初始分析并手动诊断出缓慢的互动。通过该工作流程，PubTech 能够精确找出影响网页响应速度的具体问题。例如，如果用户点击 CMP 产品中的互动来接受所有 Cookie 并随后关闭 Cookie 意见征求对话框，便会导致一项耗时较长的任务，导致界面呈现更新延迟。如下图所示，界面在耗时较长的任务完成后，界面才会更新为显示对话框已关闭。

与接受所有 Cookie 的按钮一样，用于拒绝所有 Cookie 或自定义 Cookie 偏好设置的按钮都遵循 PubConsent CMP 架构中的相同工作流程。因此，本案例研究中详述的改进影响了 CMP 产品中的一系列用户互动。

显示在用户点击“全部接受”后，任务要过多久才会阻止界面进行更新的流程按钮。一项冗长的任务包含五个步骤，这会让界面显得很迟钝。 — </ph> 直观呈现用户点击“全部接受”后会发生什么情况按钮。

这种延迟会导致在执行任务期间，从视觉上看出面板处于锁定状态。由于 INP 阻止了渲染更新的较长时间，因此对网页的 INP 产生了负面影响。

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);
  });
};

显示在用户点击“全部接受”后，长时间的任务导致界面无法更新的流程。PubConsent CMP 中的按钮已经过优化。这五个步骤现在会尽可能多出一个步骤，从而让界面更快地更新其呈现方式。 — 直观呈现使用 `yieldToMainBackground` 让出内容让浏览器更快地渲染下一次渲染（在本例中为关闭 CMP 界面）。

PubTech 如何通过渲染布局优化进一步减少 TBT

应用收益策略后，发现 CMP 的 INP 有显著提升。事实上，在显著缩短事件处理脚本的处理时长之后，就发现有机会对关闭界面操作的下一次绘制进行进一步的渲染。此操作最初设计用于从 DOM 中移除元素。这就带来了一些挑战，尤其是在具有大量 DOM 节点的网站上，会导致渲染工作量意外增加。

Chrome 开发者工具中“性能”面板的屏幕截图，其中显示了一个跟踪记录部分，其中包含用于关闭 PubConsent CMP 中界面对话框的 activity 调用堆栈。关闭界面对话框本身的任务会触发移除 DOM 节点，这会增加互动的呈现延迟时间。

为了解决从 DOM 中移除元素所需的渲染工作量增加的问题，我们引入了一种解决方案，该团队称为“延迟去渲染”。如果采用这种方法，在用户同意将其隐藏后，系统会先对 CMP 意见征求对话框应用 display: none CSS 规则。然后，使用 requestIdleCallback 将与 CMP 对话框关联的 DOM 节点的移除移至浏览器处于空闲状态的较晚时间点。事实证明，这种方法比在用户关闭意见征求对话框时移除 DOM 节点快得多。

Chrome 开发者工具中“性能”面板的屏幕截图，显示与之前相同的轨迹，但已经过优化。PubConsent CMP 的对话框关闭后，最初的操作是使用 CSS display: none 规则将其隐藏。然后，当浏览器稍后处于空闲状态时，系统会执行 DOM 节点移除。 — </ph> 开发者工具屏幕截图，其中突出显示了通过移位 DOM 移除任务实现的 INP 改进。

PubTech 如何通过改进 IAB TCF 库进一步降低 INP

在成功解决 CMP 的大部分响应问题后，我们在该平台的主要依赖项之一（TCF 库）中发现了进一步的改进机会。

此库中计算开销最大的组件是“构建字符串”以及“调度同意书”这些组件是 IAB TCF 库不可或缺的组成部分。专门针对 PubTech 的需求在单独的分支中对这些组件进行了以下优化：

将计算结果重复用于解码流程，该过程会针对需要读取用户同意情况的每个第三方回调执行。
避免并减少发布商限制编码流程（在用户表示同意后执行）中的不必要的循环。

。 <ph type="x-smartling-placeholder">

这些优化措施中的第一项缩短了 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 毫秒）。

屏幕截图：使用 PubTech CMP 的网站的原始 INP 通过率。在桌面设备上，通过率从 84% 左右提高到 99.12%。在移动设备上，通过率从约 22% 提高到 55.46%。 — </ph> 根据 HTTP Archive 和 Chrome 用户体验报告 (CrUX) 报告，使用 PubTech CMP 的网站的原始 INP 通过率。

信息中心的屏幕截图，其中显示了第 75 百分位的 RUM 数据中的 INP。从 2023 年 7 月/8 月开始，INP 略低于 500 毫秒，但到 2024 年 2 月中旬，INP 已降至 200 毫秒以内，因此被评为“良好”阈值。 — </ph> PubConsent 客户的移动设备 INP 数据改进趋势，与本案例研究中所述的 SDK 变更相关。

总结

PubTech 的客户很快就认识到，我们的优化工作取得了积极的 INP 效果和业务指标结果，并考虑利用来自其客户的宝贵真实用户监控 (RUM) 数据，进一步提升 PubConsent CMP 的性能。这些数据密切跟踪回归和进步，推动 PubTech 的持续改进工作。

作为第三方，PubTech 还意识到，他们有机会大规模提高网站性能，提高响应速度，同时避免对业务 KPI 产生负面影响。实施这些改进永远不算晚！

特别感谢 PubTech 首席技术官 Luca Coppola 为这项创新工作提供支持，以及来自 Google 的 Jeremy Wagner、Michal Mocny 和 Rick Viscomi。