前端性能指标:First Input Delay

本文是译文，关注Web Vitals Metrics，翻译系列文章中的02篇
原文连接： First Input Delay (FID)

前言

第一印象很重要，站点也是同样。第一印象的好坏将决定用户是留存仍是流失。问题是：如何才能留下好的第一印象？又如何衡量站点给用户留下的第一印象？在web网站中，用户的第一印象涉及如下几个方面：设计与视觉感染力、速度与响应快慢。用户是否喜欢网站设计很难经过API衡量，但速度和响应能够。能够用First Contentful Paint(FCP)来衡量用户访问站点时感觉到的速度快慢，不过这只是一方面。用户与页面交互时，页面响应的快慢也很重要，所以咱们引入FID metrics来衡量站点交互性、响应性。

1 FID的定义

衡量的是当用户第一次与站点进行如点击连接、按下按钮等操做到浏览器实际响应该操做（开始执行事件监听回调）的时间。

1.1 FID的得分标准

FID<100ms。这个标准须要覆盖站点75%的用户（后面将介绍些许差别）

1.2 深刻介绍FID的细节

写事件处理代码的程序猿们常认为只要事件发生了处理代码就会当即执行。但对于用户们来讲感到的却截然相反：页面加载已经完毕，尝试操做它但却没有任何反应。多么让人失望！
ID(input delay)一般发生在浏览器主线程忙于作其它的事没法响应用户操做。主线程忙于解析、执行web应用中加载的较大的JavaScript文件。解析、执行JavaScript时，主线程又会去被告知处理其它事情，所以没法执行事件监听。
给出web页面加载资源时，主线程执行示意图，如图1：

能够看到图中灰色块演示的是页面发起网络请求5个资源（CSS或者JS），而后，当每一个资源下载完成后，主线程就开始处理。形成的结果是，如黄色图块展现的那样，主线程是阶段性忙碌的。

FID发生在FCP以后，TTI(Time to Interactive)以前。这个阶段页面上已经渲染了部份内容但又没有准备好可交互。如图2：

如图所知，FCP和TTI之间时间较长，若是在这个时间段里用户尝试与页面进行交互，从浏览器收到click事件到主线程得空处理它之间存在延迟。 由于input事件发生在浏览器正在执行任务时，要等它完成后才能响应input事件。等待时长即为FID值。如图3：

---

介绍完FID发生的阶段，下面经过五个问题，介绍FID设计的细节。

（1）没有添加用户行为监听有什么影响？

FID衡量的是从接收到input事件到主线程变得空闲之间的时间差。因此有无绑定事件监听并不影响FID。实际上，不少用户行为并不须要绑定事件监听处理，但却必定须要主线程在空闲时去执行。标签如<input>, <textarea>,<raido>,<select>,<a>都须要等待主线程中正在执行的任务完成以后才能响应用户的交互行为。

（2）为何只考虑第一次输入？

只考虑第一次源于前述的第一印象很重要；另外，加载阶段的交互性问题是交互性问题的重灾区；加载时、加载后的ID问题的解决办法不互通，须要分开讨论。

（3）哪些才算是输入？

FID是加载阶段衡量页面响应性的指标，它只关注input事件和离散行为如：点击、触摸、按键事件。其它诸如滚动、缩放是连续行为，在性能方面具备大相径庭的要求（也正所以浏览器一般将它们运行在单独的线程中以掩盖其延迟执行）。从另一方面来讲，根据RAIL性能模型，FID属于R，而滚动、缩放更多的是A，须要分开讨论其性能。

（4）若是用户不和站点交互怎么办？

用户访问站点时不必定会跟页面交互，也不是全部的交互事件都跟FID有关系（如前所述）。另外，一些用户的首次交互发生在主线程忙碌时，而另外的又刚好落入主线程空闲区间。这就意味着，同一站点，有些用户得不到FID值，有些FID值低，有些又很高。从这一方面来看，分析FID跟分析其余指标稍有不一样（见后文）。

（5）为何只考虑延迟时间？

FID只是延迟的那段时间，既不包含事件处理的耗时，也不考虑事件处理后浏览器更新UI的时间。这两个时间的确也重要，也能影响用户体验。之因此不包括它们是由于，若是归入到FID之中，可能会致使程序猿们想出一些规避的办法，这将使用户体验变差。规避的办法：把事件处理逻辑包裹在异步回调（setTimeout() 和 requestAnimationFrame()）之中，能够分离事件处理回调和事件相关的任务。从指标上来看是提高了，但从用户感知方面，实际上响应变慢。

2 如何衡量FID

因为依赖用户与站点进行交互，FID只能在现场阶段衡量。

TBT能够在Lab阶段衡量，FID又与TBT相关联，在Lab阶段改进TBT也有助于FID的提高。

现场工具

Chrome User Experience Report
PageSpeed Insights
Search Console (Core Web Vitals report)
web-vitals JavaScript library

JavaScript API

（1）利用Event Timing API（W3C标准的一个提案）和PerformanceObserver

使用举例：

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

这里是简单介绍delay是如何计算的，并说明了这个计算结果只是FID的候选人，并非全部的delay结果都对FID的测量有用。而后介绍具体分发first-input Entry的几个特殊状况，好比：tab后台页面中分发的first-input、first-input发生前页面加载时也会分发的first-input Entry会在计算FID时被忽略。cache中得到的页面、iframe中页面不会分发。
须要考虑的细节不少，因此开发者们可使用JavaScript库web-vitals来测量FID，库的做用就是为你（尽量的）屏蔽这些细节差别。

（2）web-vitals库

import {getFID} from 'web-vitals';
getFID(console.log);

3 分析和报告FID数据

如第1节所述，FID值存在不定因素，因此须要关注数据的分布，也须要提升指标达标用户所占的比例。相比其余的核心指标要求的75%用户，FID最好要知足95-99%。

4 如何改进FID

咱们建议利用Lighthouse进行性能分析，关注其中的优化建议；另外，因为FID是现场指标，而Lighthouse是Lab工具，所以须要提高Lab指标TBT。更多的改进办法见以下连接：

1.为主线程“减压”
2.减小JavaScript执行耗时
3.削弱第三方代码的影响
4.压低请求数和传输数据的大小