Web性能评价指标( 二 ) _Web

确保页面的有效性、可交互性
•  Time to Interactive 可交互时间 (TTI)：页面开始加载到能够快速、可靠地响应用户输入所需的时间。
确保页面的有效性、可交互性
•  Total blocking time 总阻塞时间 (TBT)：FCP 与 TTI 之间主线程被阻塞的总时间，期间无法可靠稳定地响应用户。
确保页面的可用性，体现了不可交互程度的严重性。
•  Cumulative layout shift 累积布局偏移 (CLS)：页面在开始加载和其生命周期状态变为隐藏期间发生的所有意外布局偏移的累积分数。
确保页面令人愉快

文章插图
图片来源：https://www.lambdatest.com/blog/core-web-vitals-expert-tips-to-improve-website-performance/
从程序员角度解读
下图展示了加载一个页面，浏览器主线程和网络的使用情况，以及各个指标的耗时。

用户访问页面，导航开始，浏览器与服务器建立连接，获取html资源，再发出数个网络请求来获取所需的js，css资源。
这些资源下载完毕后，会在主线程上解析处理执行。这就导致主线程会阶段性地处于忙碌状态（图中米黄色任务块）。
DOM树构建完成后，开始绘制，页面渲染出部分内容。首次内容绘制节点即为FCP 。
如果用户在FCP后尝试与页面进行交互（例如单击一个按钮），由于主线程正处于忙碌状态，响应会有一段延迟，延迟的这段时间即为首次输入延迟FID 。用户会将较长的延迟认为页面响应缓慢或者页面已损坏，因此很可能直接离开。
5秒安静窗口：没有长任务切不超过两个正在处理的网络GET请求，此时浏览器主线程空闲并能可靠地响应用户。
可交互时间TTI是安静窗口前的最后一个长任务的结束时间，是页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所需的时间。TTI越小越好，说明用户等待的时间短。
用户收到的阻塞程度则由TTB来体现，每当出现长任务（在主线程上运行超过 50 毫秒的任务）时，主线程都被视作"阻塞状态"，浏览器无法中断正在进行的任务，长任务超过 50 毫秒的部分为阻塞时间，总阻塞时间是在 FCP 和 TTI 之间发生的每个长任务的阻塞时间总和，体现了不可交互程度的严重性。

文章插图

【Web性能评价指标】图片来源：https://web.dev/fid/
指标阈值
Google将用户体验的质量分为三个等级：好、需要改进或差，并设置了以下阈值：

文章插图
图片来源：https://developers.google.com/speed/docs/insights/v5/about

这些阈值可以作为行业性能基线，比较我们系统性能指标得分和这些阈值可以了解我们系统对应性能指标的好坏。
自定义性能指标
以用户为中心的性能指标提供了很好的性能基线，但很多情况我们需要测量更多的指标来刻画网站的完整体验。例如：
加载资源的缓存命中率：缓存机制设置的是否合理

长任务：运行开销大的代码是否阻塞主线程，比如频繁计算/过滤50M的数据
元素渲染时间：长列表需要多久能绘制到页面上
服务器响应时间：CDN是否正确设置
API的耗时：在用户使用应用的生命周期中，增删改查操作占据很大的比例。用户也许能忍受用5分钟打开一个页面，但无法接受每次提交都要等很久。API也是我们分析性能的重点。

根据系统和需要评估的性能，自定义性能指标，更全面地衡量系统性能。
小结
遇见用户抱怨性能时，不要先入为主地判定性能差，逐个排查系统可能有的性能问题，优化非最佳实践。而应该理性地以用户为中心，收集真实用户数据，衡量系统性能好坏。
从RAIL性能模型中我们了解用户眼中的性能意味着什么。用户对性能延迟的感知，Web应用生命周期中的关键动作响应、动画，空闲，加载的期望阈值，与用户体验相关的关键性能指标。