INP 惩罚沉重的分析脚本：为什么你的追踪器在主线程上
Interaction to Next Paint 是最多网站未能通过的 Core Web Vital，现场数据显示行为追踪脚本是主要原因之一。解决办法是减少发送到主线程的工作量。
Interaction to Next Paint（INP） 是开发者最常未能通过的 Core Web Vital，原因就藏在你的 <head> 里。INP 于 2024 年成为稳定的 Core Web Vital，取代了 First Input Delay，它测量的是 FID 永远无法测量的东西：页面在其整个生命周期内对每一次点击、轻触和按键保持多高的响应性。
这个指标对监控式分析所加载的那类 JavaScript 毫不留情。如果你的追踪器在主线程上执行了实质性工作，你用户的每一次交互都会继承这份成本。
INP 究竟测量什么
INP 报告页面上所有点击、轻触和按键交互在 第 75 百分位 的延迟。200 毫秒或以下为「良好」；200 到 500 毫秒为「需要改进」；超过 500 毫秒为「差」。
每次交互分为三个阶段：
- 输入延迟（input delay）——你的事件处理器甚至还无法开始的时间，因为主线程正忙。
- 处理时长——你的事件处理器回调执行所需的时间。
- 呈现延迟（presentation delay）——从回调结束到浏览器绘制下一帧之间的时间。
沉重的分析脚本会损害这三个阶段。一个解析大型 bundle、计算同意逻辑、批处理 tag manager 队列或读取布局以构建指纹的追踪器，恰好在用户试图交互时占用主线程。
长任务是其机制
浏览器在任务运行期间无法处理交互。任何运行超过 50 毫秒 的任务都是 长任务，超过 50 毫秒的部分就是死时间，期间点击会在队列中堆积。
一个同步加载并执行十几个供应商脚本的 tag manager 会产生一连串长任务。用户点击，什么也没发生，再次点击——当主线程终于空出来时，排队的输入会一次性全部触发。
这并非理论。HTTP Archive 的 2024 年 Web Almanac 发现，搭载 用户行为脚本（session replay、热力图、行为分析）的页面在移动端仅有 37% 的情况 达到良好 INP，而桌面端为 60%。同意管理脚本——这些工具所需的横幅——在移动端仅有 53% 的页面 通过 INP。本应「理解用户」的检测手段，正在主动劣化他们的体验。
避免这一切的架构
解决办法是结构性的，而不是你切换的某个开关。发送更少的代码，并让它远离关键路径。
一个隐私优先的追踪器可以小到其解析和执行从不被记为长任务。Monoid 的追踪器约 2 KB，没有依赖，不设置 cookie，也不读取布局——因此没有什么可指纹化，也没有什么沉重的东西要执行。它通过单次 keepalive 请求记录一次页面浏览，其余时间保持空闲：
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true 让请求在页面卸载后仍能完成，而不占用主线程，因此导航和 unload 绝不会被阻塞等待信标。
当你确实运行自己的脚本时，在各个工作块之间让出主线程，让排队的交互得以运行：
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() 将长任务拆成若干片段并以优先级恢复，因此第三方脚本无法在队列中插到你的续行之前。
在现场测量，而非在实验室
Lighthouse 无法报告 INP，因为 INP 只有在真实用户交互时才存在。实验室工具是估算；它们不测量响应性。
使用现场数据。Chrome User Experience Report（CrUX） 聚合了已选择加入的 Chrome 用户的真实交互，Search Console 的 Core Web Vitals 报告按 URL 分组呈现相同的数据。如果你的 CrUX INP 良好但实验室 Total Blocking Time 偏高，你还有余量；如果 CrUX INP 较差，你的用户已经在切身感受了。
隐私论点与性能论点在此交汇。一个不读取存储、不构建指纹、不加载供应商瀑布流的追踪器，在主线程上几乎无事可做——这正是它从不出现在你 INP 中的原因。监控的代价以毫秒计，而不仅仅是信任。
Comments
Loading comments…