Chrome 用户体验报告旨在帮助网络社区了解真实用户性能的分布情况和演变。迄今为止，我们的工作重点是绘制和网页加载指标，例如 First Contentful Paint (FCP) 和 Onload (OL)，这些指标有助于我们了解网站在视觉上为用户提供的性能。从 2018 年 6 月的版本开始，我们正在实验一项以用户为中心的新指标，该指标重点关注网页的互动性：First Input Delay (FID)。通过这一新指标，我们能够更好地了解网站在响应用户输入方面的响应速度。
FID 最近在 Chrome 中以源试用的形式提供，这意味着网站可以选择试用这项新的网络平台功能。同样，FID 将在 Chrome 用户体验报告中作为实验性指标提供，这意味着 FID 将在单独的“实验性”命名空间内在源试用期间可用。
FID 的衡量方式
那么，FID 到底是什么呢？以下是定义 First Input Delay 公告博文中的定义：
首次输入延迟 (FID) 衡量的是从用户首次与您的网站互动（即，点击链接、点按按钮或使用由 JavaScript 提供支持的自定义控件）到浏览器能够实际响应此次互动之间的时间。
这就像在衡量从按门铃到有人接门所需的时间。如果转化耗时较长，原因可能有很多。例如，用户可能离门很远，或者无法快速移动。同样，网页可能正忙于执行其他工作，或者用户设备可能运行缓慢。
了解 Chrome 用户体验报告中的 FID
凭借来自数百万个源的一个月 FID 数据，已经有大量有趣的数据洞见有待发现。我们来看几个查询，看看如何从 BigQuery 上的 Chrome 用户体验报告中提取这些数据洞见。
首先，我们查询 developers.google.com 的快速 FID 体验占比。我们可以将快速体验定义为 FID 小于 100 毫秒的体验。根据 RAIL 建议，如果延迟时间为 100 毫秒或更长，应该让用户感觉能够瞬间完成。
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
结果表明，此来源上 95% 的 FID 体验被视为瞬时体验。这似乎非常有用，但与数据集中的所有源站相比又如何呢？
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
此查询的结果表明，84% 的 FID 体验都不到 100 毫秒。因此，developers.google.com 高于平均水平。
接下来，我们来尝试细分这些数据，看看桌面设备和移动设备上的快速 FID 百分比之间是否存在差异。一种假设是，移动设备的 FID 值较慢，可能是因为硬件速度比桌面设备慢。如果 CPU 性能较低，则可能会长时间处于忙碌状态，并导致 FID 体验变慢。
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| form_factor | fast_fid |
|---|---|
| 桌面设备 | 96.02% |
| 手机号码 | 79.90% |
| 平板电脑 | 76.48% |
结果印证了我们的假设。与手机和平板电脑类型的设备相比，桌面设备的快速 FID 体验累积密度更高。若要了解存在这些差异的原因（例如 CPU 性能），需要在 Chrome 用户体验报告范围之外进行 A/B 测试。
我们已经了解了如何确定某个源是否有快速 FID 体验，下面我们来看几个表现出色的源站。
示例 1：http://secretlycanadian.com
此来源有 98% 的 FID 体验不到 100 毫秒。他们是如何做到的？通过分析它在 WebPageTest 中的构建方式，我们可以看到这是一个包含大量图片的 WordPress 网页，但它的 JavaScript 大小为 168 KB，在我们的实验室机器上执行大约 500 毫秒。根据 HTTP Archive 的数据，JavaScript 只占了第 28 百分位，
跨越 2.7 秒到 3.0 秒的粉色横条是 Parse HTML 阶段。在此期间，网页无法互动，并且在视觉上看起来不完整（请参见上面幻灯影片中的“3.0 秒”）。之后，所有需要处理的耗时较长任务会进行分解，以确保主线程保持静止。第 11 行的粉色线条表示 JavaScript 工作方式快速分散。
示例 2：https://www.wtfast.com
此来源具有 96% 的即时 FID 体验。该过程会加载 267 KB 的 JavaScript（HTTP Archive 中的第 38 百分位），并在实验室机器上处理该文本 900 毫秒。幻灯影片显示，页面需要大约 5 秒的时间绘制背景，大约需要 2 秒的时间绘制内容。
关于结果，最有趣的是，当主线程在 3 到 5 秒之间处于忙碌状态时，甚至看不到任何互动内容。实际上，正是此网页的 FCP 速度缓慢才提高了 FID。这个例子很好地说明了使用许多指标来表示用户体验的重要性。
开始浏览
您可以观看本周的一集《The State of the Web》详细了解 FID：
Chrome 用户体验报告中提供 FID 有助于我们建立互动体验基准。使用此基准，我们可以观察它在未来版本中的变化，或对各个源进行基准测试。如果您想开始在自己网站的现场测量中收集 FID，请转到 bit.ly/event-timing-ot 来注册源试用，然后选择“事件计时”功能。当然，请开始探索该数据集，获取关于 Web 上的互动状态的有趣数据洞见。这仍是一个实验性指标，因此，请通过 Chrome 用户体验报告论坛或 Twitter 上的 @ChromeUXReport 向我们提供反馈，并分享您的分析。