Trusted by market leaders · Client results
维度：加载状态 INP (inpls)
加载状态 (INP) 维度记录了捕获到用户交互那一刻的文档就绪状态。Chrome User Experience Report 中的每个 INP 事件都带有一个加载状态标签：loading、dom-interactive、dom-content-loaded 或 complete 之一。CoreDash 将该标签呈现为一个可过滤、可分组的维度，这样您就可以回答原始 INP 分数无法回答的问题：最糟糕的交互发生在页面生命周期的什么时候？
这个问题是两种完全不同的工程修复方案的分界线。在 loading 期间聚集的 INP 问题需要 JavaScript 延迟加载策略（deferral strategy）。在 complete 期间聚集的 INP 问题则需要削减事件处理程序的工作量、减少框架开销，或在运行时代码中拆分长任务。按加载状态分组可以为您提供这种划分，而无需任何手动埋点。
在 CoreDash 监测的站点数据中，按加载状态划分的 INP 交互分布大致为：loading 15%，dom-interactive 20%，dom-content-loaded 25%，complete 40%。大多数交互发生在页面完全加载之后，但最糟糕的 INP 分数压倒性地聚集在早期状态。
屏幕截图
为什么加载状态对 INP 很重要
Interaction to Next Paint 指标测量用户交互的完整延迟：输入延迟（input delay）、事件处理程序处理时间和到下一个渲染帧的呈现延迟（presentation delay）。在这三个组成部分中，输入延迟是最直接受用户点击或触摸那一刻浏览器正在执行的操作控制的。
在页面加载早期，主线程处于最大竞争状态。浏览器正在解析 HTML、执行同步脚本、构建 CSSOM、运行解析阻塞资源，并接连触发渲染循环。主线程上的每个长任务都是一个窗口，在此期间用户交互会被排队并等待。这种等待就是输入延迟，它是页面加载期间 INP 表现不佳的主要驱动因素。
在 document.readyState 达到 complete 后到达的交互面临的是一个更安静的主线程。页面已完成加载。如果此阶段的 INP 仍然很差，原因就不是加载竞争。而是页面在响应用户操作时运行的 JavaScript：臃肿的事件处理程序、框架重新渲染循环、脚本触发的布局抖动（layout thrashing），或者在交互期间同步执行的未优化第三方代码。
加载状态是区分这两类根因的最快过滤方式。
加载状态
loading
页面尚未完成 HTML 文档的解析。主线程正在执行同步脚本、获取解析阻塞资源并构建初始 DOM。这是用户交互最不友好的环境。输入延迟处于最高水平，因为任何长任务都会直接阻塞浏览器处理点击或触摸。在此窗口期间进行交互的用户通常是最没耐心的访问者，或者是那些在页面完成加载之前就看到可见内容的快速连接用户。他们的 INP 分数是您收集到的最差的。如果您的差评 INP 事件中有相当一部分带有 loading 状态，请将非关键脚本移至 defer 或 async，并消除视口上方的解析阻塞资源。
dom-interactive
当 HTML 被完全解析且 DOM 已构建完成，但图像、样式表和延迟脚本等子资源仍在加载时，document.readyState 达到 interactive。延迟脚本在此点开始执行，这意味着主线程仍可能被大量占用。框架水合（hydration）通常从这里开始。这是一个危险窗口，因为页面对用户看起来已经就绪，但主线程仍然很忙。输入延迟仍然很高。如果糟糕的 INP 集中在这里，修复方法与 loading 相同：减少在 DOM 解析完成后立即运行的同步工作量。
dom-content-loaded
DOMContentLoaded 事件已触发。DOM 已完成，延迟脚本已执行。到此为止，大多数 JavaScript 框架已完成其初始水合过程。主线程工作量下降，交互开始获得更快的响应。此状态下的 INP 分数通常优于前两个状态，但与 complete 相比仍然偏高。如果您发现差评交互集中在这里，请查看您的框架或应用程序脚本在 DOMContentLoaded 处理程序中正在执行的操作，以及水合工作是否可以分块或出让（yielding）以允许在任务之间处理输入。
complete
当包括图像、字体和第三方 iframe 在内的所有资源都已加载完成时，document.readyState 达到 complete。这是页面在剩余会话期间运行的稳态。此状态下糟糕的 INP 是一个纯粹的运行时问题。页面已完成加载。如果主线程仍在阻塞交互，则原因在于交互期间的 JavaScript 执行：事件处理程序执行了太多的同步工作、框架更新触发了昂贵的布局重新计算，或第三方脚本持续运行长任务。修复方法不在于延迟加载，而在于降低用户实际点击时所发生操作的成本。
调试工作流程
第 1 步：在 CoreDash 中按加载状态过滤。 打开 INP 细分表格并按加载状态分组。识别哪个状态承载了最高比例的差评（超过 200ms）交互。这会立即告诉您是在处理加载问题还是运行时问题。
第 2 步：交叉引用 URL 和设备。 将加载状态维度与 URL 维度结合使用，找出哪些特定页面在早期加载状态期间产生差评交互。移动设备在加载期间受到的影响不成比例，因为较慢的 CPU 会延长每个长任务。
第 3 步：根据状态匹配修复方案。 对于 loading 和 dom-interactive，使用 优化 INP 指南 审计您的脚本加载策略。将脚本移至 defer，消除渲染阻塞资源，并使用 scheduler.yield() 拆分长的初始化任务。对于 complete，在 Chrome DevTools 中分析您的事件处理程序，并减少它们在每次交互中触发的同步工作。
工程师经验法则
如果您的差评 INP 交互中有超过 30% 被标记为 loading 或 dom-interactive，那么您的 INP 问题就是页面加载问题，JavaScript 延迟加载将产生最大的改进。如果超过 60% 的差评交互被标记为 complete，那么您的 INP 问题就是运行时问题，您需要优化事件处理程序的成本，而不是脚本加载顺序。加载状态 (INP) 通过一个表格视图就能做出这一判断，无需实验室会话或自定义埋点。