当我们考虑评估应用程序的性能时，我们倾向于转向后端环境。我们描述了诸如资源利用率，磁盘I / O操作，内存泄漏检测，响应时间等指标。但是，考虑到当今网络交互的复杂性，认为我们还需要了解如何将性能评估工作重点放在UI上并没有那么疯狂。

但是，我们该怎么做呢？浏览器并没有真正在客户端磁盘上执行I / O操作，我们可以以某种方式测量内存利用率吗？我们还能分析什么？

的确，如果要非常详细，您将想出一个自定义指标列表，其中一个针对您的上下文。在这里，我列出了总体上衡量UI性能时要考虑的前5个指标。

互动时间（TTI）

通过该指标，您可以了解用户与应用程序进行交互需要花费多长时间。一件事是呈现它，而另一件事是使它具有交互性。此指标取决于以下几点：

布局稳定。可见的所有内容均已加载。
CPI主线程是免费的。如果您仍在加载脚本或处理某些内容，则您的应用程序将不是交互式的。在线程释放之前，用户的单击和其他操作将被忽略（或排队）。

因为它直接影响应用程序的用户体验（UX），所以它已成为一个非常相关的指标。这不仅与冷数字有关，还与用户体验UI的方式有关。尽管这听起来似乎是很主观的事情，但是通过使用诸如TTI之类的指标，我们可以开始更接近于此。

测量TTI

计算您网站的TTI最快，最简单的方法是在Google DevTools上使用Lighthouse。作为Lighthouse生成的报告的一部分，您具有TTI号：

优化您的TTI

改善TTI的一种关键方法是减少脚本的加载时间。脚本处理和加载时间将是TTI高的主要原因，因此请考虑以下几点：

删除未使用的脚本，浏览器需要解释且不使用的所有脚本，这只是从加载时间中窃取了几秒钟。
将您的脚本分成多个较小的文件。这也有助于浏览器优化这些脚本的加载和解释方式。
动态加载脚本，尤其是那些来自外部资源的脚本，您实际上无法进行任何拆分或更改。

但是请注意，主线程只有在没有持续时间超过50毫秒（至少）5秒钟的任务时，才被视为“可靠的交互”。这为TTI的“足够好”值设置了一个下限，如果5秒或更短，则应该足够好，而少的则被认为是很好的。

首次输入延迟（FID）

与TTI相关，此度量标准度量从用户执行第一个输入操作那一刻起您的应用程序响应所花费的时间。虽然听起来像TTI一样可怕，但这两个指标之间的差异是巨大的：

TTI衡量您的应用准备好开始响应交互所花费的时间。您不需要用户对此进行衡量，这全都在于确保主线程是空闲的并且一切都已加载。但是最后，它可以衡量您的应用进行交互所花费的潜在时间。
另一方面，FID要求用户对其进行测量，因为FID会跟踪执行交互后实际响应所花费的时间。

理想情况下，您希望FID低，因为这表明您的应用程序从一开始就响应迅速。

您如何衡量FID？

由于正确衡量FID需要真正的用户互动，因此您不能简单地浏览网站并获得该价值。但是，您可以在应用程序中添加代码以获取该信息。拥有之后，您就可以根据自己的意愿去做。Google有一个开放源代码脚本，您可以在页面内直接使用该脚本来度量该指标：https：//github.com/GoogleChromeLabs/first-input-delay

改善您的FID时间

改善首次输入延迟时间并非易事，因为它与代码的结构和逻辑紧密相关。但是，来自Google的Philip Walton提出了一种称为“从空闲到紧急”的技术，该技术试图在不实际锁定主线程的情况下最大化主线程的处理时间。从本质上讲，它取决于决定何时加载所需的资源：浏览器何时处于空闲状态并且具有可用的处理能力，或者何时确实需要该资源。它试图弥合渴望和懒惰的资源加载之间的差距。Philip的文章涵盖了非常详细的实现方式，以解决您是否需要缩短“首次输入延迟”时间的情况下如何实现这一概念。

总封锁时间（TBT）

“总阻止时间”是页面加载资源，解释JavaScript文件以及谁知道后台还有哪些其他任务时页面无响应的时间长度。本质上，主线程忙于处理您扔给它的所有内容，以致于无法响应用户的输入。它涵盖了从第一个内容丰富的涂料（FCP）到TTI的时期。

虽然TBT听起来很像是另一种描述TTI的方式，但实际上它们并没有太大不同。考虑使主线程具有以下4个连续任务：

任务1：300ms
任务2：55毫秒
任务3：45毫秒
任务4：50毫秒

就像我在上面说的那样，前两个任务被认为是“长任务”，因为它们的长度超过50毫秒。实际上，“阻塞时间”将是最初50ms内的所有时间，这将为总值450ms的任务产生总计255ms的“总阻塞时间”。考虑到这一点，TBT和TTI有何不同？考虑到3个51ms的任务分散在10秒内，主线程在5秒钟以上的时间内没有“阻塞时间”是不可能的：

上图显示了给定的场景。此处的总阻止时间为3毫秒，而实际的TTI为15秒。现在，考虑如果您没有一个3个微任务，而是一个任务耗时10秒，将会发生什么情况。这种新情况的TBT为9950毫秒（前50毫秒的总时间），但是TTI将保持不变。但是，UX并不相同，这就是为什么即使TTI保持不变，也要最小化TBT的原因。

测量TBT

总阻止时间可以使用TTI之类的Google Chrome浏览器上的Lighthouse进行测量。实际上，如果您生成报告，则可以在TTI下看到它。

改善技术性贸易壁垒

可能会影响到TBT的因素很多，因此，一个很好的经验法则是要注意Lighthouse在其报告底部提出的建议。其中一些将帮助您降低人数。通常，认为300毫秒或更低的TBT足够好，因此，如果您坐在那里，暂时不必担心。但是，如果您的数字不好，例如上面的屏幕截图，您可能需要考虑按照本指南进行操作，在该指南中，您可以了解如何确定导致长任务阻塞主线程的原因。请记住，首先您需要确定哪些任务持续时间超过50毫秒，然后开始处理较慢的任务。解决慢速TBT尚无通用的肯定方法，这需要时间和耐心，但可以做到。

累积版式移位（CLS）

换句话说，在加载所有内容时，您的布局会移动多少。如果您的布局结构不正确，则缓慢加载的图像或字体（仅举两个例子）可能会导致元素在用户甚至没有机会与它们进行交互之前就进行移动（或移动）。甚至更糟的是，当它与加载图像的元素交互时，突然看不到“取消”按钮，而“立即购买”按钮正好位于另一个按钮的位置。较高的CLS本质上会产生糟糕的UX，因此您想尝试尽可能降低此数字。

衡量您网站的CLS

Lighthouse的默认报告已经为您提供了关于什么是CLS索引的好主意。

您可以在TBT值下找到它。另一方面，如果您想将此值合并到自定义报告中，或者想要更好地控制它的计算方式，则可以利用Layout Instability API，它为您提供了测量元素如何在您的元素周围移动所需的一切。网页。这种选择使您可以完全控制计算及其处理方式，但是请注意，这不是一个简单的公式，需要很多考虑（例如，iFrame和后台页面会发生什么）。因此，相反，如果您正在寻找自定义替代方案，则可以查看Google的WebVitals API，该API提供了一种非常方便的getCLS方法。

改善您的CLS

CLS是由于布局中的意外更改而发生的，因此在编写HTML和CSS时请考虑以下准则：

请勿在其他元素上插入会导致布局偏移的元素。当插入突然的通知或警报框时，通常会发生这种情况。尝试使用其他替代方法，这些替代方法不会影响页面上其他元素的位置。
始终将大小属性添加到您的图像和视频元素。这样，浏览器便知道如何在加载之前为其保留适当的位置。
避免动画引起布局更改。有些过渡效果很好，不需要任何移动，因此考虑使用过渡效果，而不是移动元素或更改影响布局的大小，即使只是几帧。

评估前端性能

在生产中监视Web应用程序的性能可能具有挑战性并且很耗时。Asayer是一个前端监视工具，可重播用户所做的一切，并显示您的应用程序在每个问题上的行为。这就像在浏览用户肩膀时打开浏览器的检查器。

通过Asayer，您可以重现问题，汇总JS错误并监视应用程序的性能。Asayer提供了用于捕获Redux或VueX存储状态以及用于检查Fetch请求和GraphQL查询的插件。

Asayer Redux

调试愉快，适合现代前端团队-免费开始监视您的Web应用程序。

首次合格涂料（FCP）

“第一个内容丰富的绘画”是指页面绘制第一个非白色元素所花费的时间。这是一个很重要的指标，因为渲染内容所花费的时间越长，用户在空白页上看到的时间就越长，并且如果发生的时间足够长，那么他们甚至可能会认为您的网站无法正常工作。反过来，这将导致用户离开寻找替代方案。但是请注意，该度量标准引用了呈现的第一部分内容，它没有引用整个页面呈现所花费的时间，但是它仍然非常相关，因此您应该密切注意该度量标准。毕竟，我们正在衡量您的用户在视觉上感知您的网站的速度。

测量FCP

现在，谷歌浏览器上的Lighthouse已经为您提供了捕获此指标的方法，这不足为奇。您可以在以下屏幕截图中看到它：

与其他情况一样，如果您需要对计算和数据进行更多控制，则可以使用Paint Timing API。良好的FCP被认为在1到3秒之间。如果超过3秒，那么您真的需要担心对其进行改进。

改善您的FCP

毕竟，您的First Contentful Paint不仅取决于您的前端代码，这是从您的服务器收到响应后发生的第一件事。因此，当您想改善FCP时，请考虑以下几点：

减少服务器的响应时间。这将导致浏览器更快地开始处理和解释响应。这可能是改善服务器端代码，或者改善如何提供静态资源，例如将图像移动到高质量CDN。
考虑使用defer以下方法加载非关键资源（即脚本和CSS样式表）：

复制代码

或使用以下小片段异步加载样式表：

<!-- Fallback for when JavaScript is disabled, but in this case CSS can’t be loaded asynchronously. -->
<noscript><link rel="stylesheet" href="https://juejin.cn/post/style.css"></noscript>
复制代码

该代码段media以“ print”的形式加载样式表，这会导致浏览器异步加载它，但是一旦页面加载完毕，它将把其媒体类型更改为“ all”（注意onload属性）。如果noscript禁用了JS，则存在该标记，因为在这种情况下，onload不会触发该事件。