INP 超标来自客服 SDK 初始化 和自身脚本无关

这个坑值得记一笔。文章页 INP 到 320ms，Lighthouse 显示自身脚本都很快，最后定位到客服 SDK 初始化时同步读取本地存储并插入三百个 DOM 节点。

刚开始盯着「点击事件冒泡到 SDK 的全局监听」，折腾了半个多小时，排掉了。

排查方向其实有限，先把可能性排一排。客服 SDK 在首屏同步初始化，长时间占住主线程；初始化时批量插入节点，触发长任务；SDK 加载后还发起一次轮询请求。

动手时先看长任务来自哪个脚本

npx lighthouse https://www.example.com/ --only-audits=long-tasks --chrome-flags="--headless"

随后把 SDK 改成点击后再加载

document.getElementById('chat').addEventListener('click', () => import('/chat.js'));

延迟初始化到空闲时段

requestIdleCallback(() => window.chatInit && window.chatInit());

复核 INP 分位

curl -s "https://www.example.com/crux?url=https://www.example.com/" | Select-String inp

排查用的命令都是临时敲的，没有写成脚本，事后才整理。

手上没有现成的复现脚本，就照着线上请求手工拼了一个。

别只看报错消失，验证要多做一步。INP 从 320ms 降到 180ms 以内，长任务数量减少一半，客服按钮仍能正常打开。

容易忽略的是，第三方 SDK 最容易藏在全局监听里，先看长任务的归属再决定动谁。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。