Trusted by market leaders · Client results
维度：加载状态 INP (inpls)
加载状态 (INP) 维度记录了捕获用户交互那一刻的文档就绪状态。Chrome 用户体验报告中的每个 INP 事件都带有一个加载状态标签：loading、dom-interactive、dom-content-loaded 或 complete。CoreDash 将该标签呈现为可筛选、可分组的维度。这能帮你回答原始 INP 分数无法回答的问题：最差的交互发生在页面生命周期的哪个阶段？
这个问题是两种截然不同的工程修复方案的分水岭。集中在 loading 阶段的 INP 问题，需要 JavaScript 延迟策略。集中在 complete 阶段的 INP 问题，则需要精简事件处理程序、降低框架开销，或拆分运行时代码中的 long task。按加载状态分组让你无需手动插桩，就能做出这种区分。
在 CoreDash 监控的各个网站数据中，按加载状态划分的 INP 交互分布大约为：loading 占 15%，dom-interactive 占 20%，dom-content-loaded 占 25%，complete 占 40%。大多数交互发生在页面完全加载之后。但最差的 INP 分数绝大多数集中在早期状态。
截图
为什么加载状态对 INP 很重要
Interaction to Next Paint 指标测量用户交互的完整延迟：输入延迟、事件处理时间，以及下一帧绘制的呈现延迟。在这三部分中，输入延迟最直接受控于用户点击或触控时浏览器正在执行的操作。
在页面早期加载阶段，main thread 的竞争最激烈。浏览器正在解析 HTML、执行同步脚本、构建 CSSOM、运行 render blocking 资源，并连续触发渲染周期。main thread 上的每一个 long task 都会导致用户交互被迫排队等待。这种等待就是输入延迟，它是页面加载期间导致 INP 变差的主要原因。
在 document.readyState 达到 complete 后发生的交互，面对的是相对空闲的 main thread。浏览器已完成加载。如果此时 INP 依然很差，原因就不在加载竞争。问题出在页面响应用户操作时运行的 JavaScript：臃肿的事件处理程序、框架重渲染周期、脚本触发的布局抖动，或是交互期间同步执行的未优化第三方代码。
加载状态是区分这两种根本原因最快的筛选条件。
各个加载状态
loading
页面尚未完成解析 HTML 文档。main thread 正在执行同步脚本、获取阻塞解析的资源并构建初始 DOM。这是对用户交互最恶劣的环境。输入延迟达到最高，因为任何 long task 都会直接阻碍浏览器处理点击或触控。在这个阶段进行交互的用户，通常是最不耐烦的访客，或者是网速极快、在页面加载完成前就看到可见内容的访客。他们的 INP 分数将是你收集到的最差数据。如果你有相当比例的差 INP 事件带有 loading 状态，请将非关键脚本改为 defer 或 async，并消除首屏中阻塞解析的资源。
dom-interactive
当 HTML 完全解析且 DOM 构建完成时，document.readyState 会变为 interactive。但此时图片、样式表和延迟脚本等子资源仍在加载。延迟脚本在此刻开始执行，这意味着 main thread 仍可能被大量占用。框架的注水（hydration）通常从这里开始。这是一个危险的窗口期，因为页面在用户看来已就绪，但 main thread 依然忙碌。输入延迟依然偏高。如果差 INP 集中在此刻，修复方案与 loading 相同：减少 DOM 解析完成后立即执行的同步工作量。
dom-content-loaded
DOMContentLoaded 事件已触发。DOM 构建完毕，延迟脚本也已执行。此刻，大多数 JavaScript 框架已完成初始注水。main thread 工作量下降，交互开始获得更快的响应。这个状态下的 INP 分数通常比前两个阶段好，但相比 complete 依然偏高。如果差交互集中在这里，请检查你的框架或应用脚本在 DOMContentLoaded 处理程序中执行了什么。评估注水工作能否分块或进行 yield，以便在任务之间留出时间处理输入。
complete
当图片、字体和第三方 iframe 等所有资源加载完毕时，document.readyState 变为 complete。这是页面在剩余会话中的稳定运行状态。此阶段的差 INP 纯粹是运行时问题。页面已经加载完毕。如果 main thread 仍在阻塞交互，原因在于交互期间执行的 JavaScript：事件处理程序执行了过多同步工作，框架更新触发了昂贵的布局重算，或者第三方脚本在持续运行 long task。修复方向不是延迟加载，而是要降低用户真正点击时所触发操作的性能开销。
调试工作流
第一步：在 CoreDash 中按加载状态筛选。打开 INP 明细表，按加载状态分组。找出哪个状态包含最高比例的差交互（超过 200 毫秒）。这能立刻让你判断出当前是加载问题还是运行时问题。
第二步：结合 URL 和设备交叉对比。将加载状态维度与 URL 维度结合，找出哪些特定页面在早期加载状态下产生了差交互。移动设备在加载期间受到的影响尤其严重，因为较慢的 CPU 会拉长每一个 long task。
第三步：根据状态对症下药。对于 loading 和 dom-interactive，请使用 Optimize INP 指南 来审计脚本加载策略。将脚本设为 defer，消除 render blocking 资源，并使用 scheduler.yield() 拆分漫长的初始化任务。对于 complete，在 Chrome DevTools 中分析事件处理程序，减少每次交互触发的同步工作量。
工程经验法则
如果超过 30% 的差 INP 交互被标记为 loading 或 dom-interactive，你的 INP 属于页面加载问题，采用 JavaScript 延迟策略会带来最大的性能提升。如果超过 60% 的差交互标记为 complete，你的 INP 属于运行时问题。你需要优化事件处理程序开销，而不是脚本加载顺序。加载状态 (INP) 能在一个表格视图中直接帮你做出判断，无需实验室测试或自定义插桩。