有关衡量网络响应能力的计划的最新动态。
今年早些时候，Chrome 速度指标团队分享了一些 新的响应性指标我们希望设计一个指标， 各个事件的端到端延迟时间，让您更全面地了解 网页在整个生命周期内的整体响应情况
最近几个月，我们在这一指标方面取得了很大进展， 我想与您分享我们计划如何衡量互动延迟时间的最新消息 介绍几个具体的汇总选项， 网页的整体响应速度
我们很想获得开发者和网站所有者的反馈 下面哪个选项最能代表 网页的响应速度。
测量互动延迟时间
回顾一下，First Input Delay (FID) 指标捕获的是 输入延迟时间的延迟时间部分。也就是说， 当用户与页面交互时，直到事件处理脚本被触发时， 运行。
通过这个新指标，我们计划扩大该指标的适用范围，以涵盖整个事件 时长，从 用户初始输入，直到在所有事件处理脚本完成后绘制下一帧 。
我们还计划
互动次数
而非单个事件“互动”是指
作为同一逻辑用户手势（例如：
pointerdown、click、pointerup）。
衡量一组单个事件的总互动延迟时间 我们正在考虑两种可能的方法：
- 事件时长上限：互动延迟时间等于最长延迟时间 互动组中任意事件的单个事件时长。
- 事件总时长：互动延迟时间是所有事件的总和 并忽略所有重叠的情况
例如，下图展示了包含按键交互的
即 keydown 和 keyup 事件。在本示例中，存在时长重叠的
。要测量按键交互的延迟时间，
我们可以使用 max(keydown duration, keyup duration) 或 sum(keydown duration, keyup duration) - duration overlap：
每种方法各有利弊，我们希望收集更多数据和 反馈，然后再最终确定延迟时间定义。
<ph type="x-smartling-placeholder">。 <ph type="x-smartling-placeholder">汇总每个网页的所有互动
一旦能够测量出所有互动的端到端延迟时间，接下来， 为网页访问定义一个总分，其中可能包含 一次互动。
在了解了众多选项后，我们缩小了选择范围， 我们在下文中概述的每种策略，目前 如何在 Chrome 中收集真实用户数据我们计划发布 收集到足够的数据后，就能轻松发现新发现，但我们还在研究 获得网站所有者的直接反馈 能最准确地反映其网页上的互动模式。
汇总策略选项
为帮助解释以下各种策略，不妨以一个网页访问示例为例 包括以下四项互动：
| 互动 | 延迟时间 |
|---|---|
| 点击 | 120 毫秒 |
| 点击 | 20 毫秒 |
| 按键效果 | 60 毫秒 |
| 按键效果 | 80 毫秒 |
最差互动延迟时间
网页上发生的最长单个互动延迟时间。由于存在 上面列出的互动示例，则最糟糕的互动延迟时间是 120 毫秒。
预算策略
用户体验 研究 表明用户可能不会认为延迟时间低于特定阈值， 负面。根据此次调研，我们正在考虑多种预算策略 针对每种事件类型使用以下阈值：
| 互动方式 | 预算阈值 |
|---|---|
| 点击/点按 | 100 毫秒 |
| 拖动 | 100 毫秒 |
| 键盘 | 50 毫秒 |
所有这些策略都只会考虑超过 每次互动的预算阈值。以上面的网页访问示例为例， 超出预算的金额如下所示：
| 互动 | 延迟时间 | 超出预算的延迟时间 |
|---|---|---|
| 点击 | 120 毫秒 | 20 毫秒 |
| 点击 | 20 毫秒 | 0 毫秒 |
| 按键 | 60 毫秒 | 10 毫秒 |
| 按键 | 80 毫秒 | 30 毫秒 |
超出预算的最严重互动延迟时间
超出预算的最大单次互动延迟时间。对于上面的示例，
得分为 max(20, 0, 10, 30) = 30 ms。
超过预算的总互动延迟时间
预算范围内所有互动延迟时间的总和。对于上面的示例，
得分为 (20 + 0 + 10 + 30) = 60 ms。
超出预算的平均互动延迟时间
预算超支的互动总时长除以
互动。对于上面的示例，得分为 (20 + 0 + 10 + 30) / 4 = 15 ms。
高分位数近似值
除了计算预算范围内最大的互动延迟时间之外， 也可以考虑使用高分位数近似， 网页经常会进行大量互动， 离群值。我们确定了两种可行的高分位数近似策略 我们喜欢：
- 方法 1：跟踪 预算。每 50 次新的互动之后， 然后从当前的 50 次互动中选择最大的互动次数。 最终值将是预算范围内最大的剩余互动。
- 方法 2：计算超过预算的最多 10 次互动，然后选择 具体取决于总互动次数。给定 N 总互动次数，请选择 (N / 50 + 1) 第 1 个最大值或第 10 个值 。
在 JavaScript 中衡量这些选项
以下代码示例可用于确定第一个 上述三种策略请注意，目前还无法衡量 网页上的总互动次数，所以本例并不是 包括预算策略的平均互动数或 分位数近似策略。
const interactionMap = new Map();
let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;
new PerformanceObserver((entries) => {
for (const entry of entries.getEntries()) {
// Ignore entries without an interaction ID.
if (entry.interactionId > 0) {
// Get the interaction for this entry, or create one if it doesn't exist.
let interaction = interactionMap.get(entry.interactionId);
if (!interaction) {
interaction = {latency: 0, entries: []};
interactionMap.set(entry.interactionId, interaction);
}
interaction.entries.push(entry);
const latency = Math.max(entry.duration, interaction.latency);
worstLatency = Math.max(worstLatency, latency);
const budget = entry.name.includes('key') ? 50 : 100;
const latencyOverBudget = Math.max(latency - budget, 0);
worstLatencyOverBudget = Math.max(
latencyOverBudget,
worstLatencyOverBudget,
);
if (latencyOverBudget) {
const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
}
// Set the latency on the interaction so future events can reference.
interaction.latency = latency;
// Log the updated metric values.
console.log({
worstLatency,
worstLatencyOverBudget,
totalLatencyOverBudget,
});
}
}
// Set the `durationThreshold` to 50 to capture keyboard interactions
// that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});
反馈
我们希望鼓励开发者 。如果您发现任何问题，请告诉我们。
如果您对此处所述的方法有任何一般性反馈，请通过电子邮件发送给 web-vitals-feedback Google 包含“[自适应指标]”的分组。我们真诚期待 期待听到您的想法！