Trusted by market leaders · Client results
维度：加载状态 INP (inpls)
加载状态 (INP) 维度记录了捕获用户交互那一刻的文档就绪状态 (document ready state)。Chrome 用户体验报告中的每个 INP 事件都带有一个加载状态标签：loading、dom-interactive、dom-content-loaded 或 complete 之一。CoreDash 将该标签呈现为可过滤、可分组的维度，以便您可以回答原始 INP 分数无法回答的问题：最糟糕的交互发生在页面生命周期的哪个阶段？
这个问题是两种截然不同的工程修复方案的分水岭。如果在 loading 期间集中出现 INP 问题，则需要采用 JavaScript 延迟策略。如果在 complete 期间集中出现 INP 问题，则需要削减事件处理程序的工作量、减少框架开销，或者分解运行时代码中的长任务。按加载状态分组可以让您无需任何手动插桩即可获得这种区分。
在 CoreDash 监控站点的所有数据中，按加载状态划分的 INP 交互分布大致为：loading 15%、dom-interactive 20%、dom-content-loaded 25%、complete 40%。大多数交互发生在页面完全加载之后，但最差的 INP 分数绝大多数集中在早期状态。
截图
为什么加载状态对 INP 很重要
Interaction to Next Paint 指标测量用户交互的完整延迟：输入延迟、事件处理程序处理时间以及到下一个绘制帧的呈现延迟。在这三个部分中，输入延迟是最直接受用户点击或轻触瞬间浏览器正在执行的操作控制的。
在页面加载初期，主线程处于最大竞争状态。浏览器正在解析 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 框架到此时已经完成了它们的初始注水 (hydration) 传递。主线程工作量下降，交互开始得到更快的响应。此状态期间的 INP 分数通常优于前两个状态，但与 complete 相比仍然偏高。如果您看到这里集中出现了糟糕的交互，请检查您的框架或应用程序脚本在 DOMContentLoaded 处理程序中正在做什么，以及注水工作是否可以分块或进行 yield 以允许在任务之间进行输入处理。
complete
当包括图片、字体和第三方 iframe 在内的所有资源都已加载完毕时，document.readyState 达到 complete。这是页面在会话剩余时间内运行的稳定状态。此状态下糟糕的 INP 纯粹是一个运行时问题。页面加载已经完成。如果主线程仍然阻塞交互，原因出在交互期间您的 JavaScript 执行中：事件处理程序进行了过多的同步工作、框架更新触发了昂贵的布局重新计算，或者第三方脚本在持续运行长任务。修复方法不在于延迟。而在于降低用户实际点击时发生的操作的成本。
调试工作流
第 1 步：在 CoreDash 中按加载状态过滤。 打开 INP 分解图表并按加载状态分组。确定哪个状态所占的糟糕交互（超过 200 毫秒）比例最高。这会立即告诉您您面临的是加载问题还是运行时问题。
第 2 步：与 URL 和设备交叉引用。 将加载状态维度与 URL 维度结合起来，找出哪些特定页面在早期加载状态期间产生糟糕的交互。移动设备在加载期间受到的影响尤为严重，因为较慢的 CPU 会延长每一个长任务。
第 3 步：将修复方法与状态相匹配。 对于 loading 和 dom-interactive，请使用 Optimize INP 指南审核您的脚本加载策略。将脚本移至 defer，消除阻塞渲染的资源，并使用 scheduler.yield() 来分解冗长的初始化任务。对于 complete，请在 Chrome 开发者工具中对您的事件处理程序进行性能分析，并减少它们在每次交互中触发的同步工作量。
工程经验法则
如果您超过 30% 的糟糕 INP 交互被标记为 loading 或 dom-interactive，则您的 INP 问题是页面加载问题，延迟 JavaScript 将带来最大的改善。如果超过 60% 的糟糕交互被标记为 complete，则您的 INP 问题是运行时问题，您需要优化事件处理程序的成本，而不是脚本加载顺序。加载状态 (INP) 可以在一个表格视图中做出判断，而无需进行实验室会话或自定义插桩。