共计 3924 个字符,预计需要花费 10 分钟才能阅读完成。
作为开发咱们都晓得,页面性能很重要,一个性能良好的页面能够给用户带来十分好的用户体验。那么,怎么能晓得本人写的页面性能是好是坏呢?
Lighthouse
是 Chrome
提供给开发者用来测量页面性能的工具。通过Lighthouse
,咱们能够很分明的看到页面的性能状况。
以后页面的性能总体得分为 96
分,是十分优异的。
这个分数是怎么得进去的?这些指标又跟分数有什么样的关系呢?让咱们来一探到底。
Lighthouse
性能分数的计算
上图中提到了 Lighthouse
是基于 FCP (First Contentful Paint)
、SI (Speed Index)
、LCP (Largest Contentful Paint)
、TBT (Total Blocking Time)
和 CLS (Cumulative Layout Shift)
这5
个指标来计算性能得分的。
点击“查看计算机”,能够看到以下页面:
页面中蕴含了性能的指标、数据 (value)、得分(Metric Score) 以及权重(Weighting),而最终的性能得分就是这些指标分数的加权平均值。即(从上往下开始计算):(100*0.1 + 95*0.1 + 84*0.25 + 100 * 0.3 + 100 * 0.25) / (0.1+ 0.1+ 0.25+0.3+0.25)
约等于 96
(四舍五入)。
加权平均值: 行将各数值乘以相应的权数,而后加总求和失去总体值,再除以总的单位数。点击理解更多
指标的定义
Web
指标是 Google
创始的一项新打算,旨在为网络品质信号提供对立领导,这些信号对于提供杰出的网络用户体验至关重要。
指标定义的框架
长久以来,网络性能都是通过 load
事件进行测量的。然而通过这个事件获取到的数据,跟理论的用户体验并不是很相符。
举个例子:服务器能够通过加载一个“最小”的页面来进行响应,响应实现之后,再通过异步获取次要的页面信息进行展现。通过 load
事件进行测量,性能上看起来很优良,然而用户实际上看到页面的时候工夫可能变得更长了(因为多了一次申请)。这显著跟实在的用户体验不匹配。
为了能更精确地测量用户的网页性能体验,Chrome
团队成员与 W3C Web
性能工作组独特单干,围绕几个关键问题构建出了指标的框架:
能够依据这几个点去对指标进行定义,这些都是跟用户非亲非故的。
指标类型
用户对性能感知相干的指标能够分为以下几类:
- Perceived load speed 感知加载速度: 页面在屏幕上加载并渲染出所有视觉元素的速度。
- Load responsiveness 加载响应度: 为了使组件对用户交互作出疾速响应,页面加载和执行任何所需 JavaScript 代码的速度。
- Runtime responsiveness 运行时响应度: 页面在加载后,对用户交互的响应速度。
- Visual stability 视觉稳定性: 页面上的元素是否会呈现让用户感到意外的偏移,并对用户交互造成潜在的烦扰?
- Smoothness 平滑度: 过渡和动画在页面状态切换的过程中是否具备稳固的帧速率和顺滑的流动性?
通过上述的性能指标类型表明,只用一项指标去捕捉页面的所有性能特色是远远不够的。
外围指标
多年来,Google
提供了许多性能测量和性能报告工具,导致一些开发者发现大量的工具和指标令人应接不暇。
开发者想要理解的是他们提供给用户的体验品质是怎么的,并非每个人都须要成为性能专家。咱们并不需要去理解所有的指标,只须要专一于一些重点的指标就能够了。
外围 Web
指标的形成会随着工夫的推移而倒退。以后针对 2020
年的指标形成侧重于用户体验的三个方面——加载性能、交互性和视觉稳定性——并包含以下指标(及各指标相应的阈值):
这 3
个指标能够作为网站的一组通用指标,但并不是说咱们只须要关注以上这几个外围指标就能够了。在某些状况下,咱们将引入新指标来查漏补缺,来捕捉残缺的性能全貌,可能体现出你网页的实在用户体验才是最佳的指标。
其余一些重要的指标:
- First contentful paint 首次内容绘制 (FCP):测量页面从开始加载到页面内容的任何局部在屏幕上实现渲染的工夫。
- Time to Interactive 可交互工夫 (TTI):测量页面从开始加载到视觉上实现渲染、初始脚本(如果有的话)实现加载,并可能疾速、牢靠地响应用户输出所需的工夫。
- Total blocking time 总阻塞工夫 (TBT):测量 FCP 与 TTI 之间的总工夫,这期间,主线程被阻塞的工夫过长,无奈作出输出响应。
指标阈值定义
规范
在为外围 Web
指标建设阈值时,Chrome
团队首先确定了每个阈值必须满足的规范。
高质量的用户体验
- 确保满足外围
Web
指标 ” 良好 ” 阈值的页面可能提供高质量的用户体验。 - 人类感知和
HCI
钻研,有时会应用单个固定阈值来进行概括,但底层钻研中通常会用范畴值来示意,聚合和匿名Chrome
指标数据也显示出了平滑且间断的散布。所以 指标的阈值会用范畴值来示意。
可通过现有网络内容实现
为了确保网站所有者可能胜利地优化他们的网站并满足 ” 良好 ” 阈值,咱们要求这些阈值对于网络上现有的内容是能够实现的。
例如,尽管零毫秒是现实的 LCP
“ 良好 ” 阈值,并且能够带来即时加载体验,但因为网络和设施解决提早,零毫秒的阈值实际上在大多数状况下都无奈实现。因而,对于外围Web
指标来说,零毫秒不是一个正当的LCP
“ 良好 ” 阈值。
“ 良好 ” 阈值 :在评估外围Web
指标的候选 ” 良好 ” 阈值时,咱们会依据 Chrome
用户体验报告 (CrUX)
中的数据验证这些阈值是否能够实现。为了确认一个阈值是能够实现的,要求目前至多有 10%
的域满足 ” 良好 ” 阈值。
“ 欠佳 ” 阈值: 通过确定以后只有多数域未能达到的性能程度来建设 ” 欠佳 ” 阈值。除非有 ” 欠佳 ” 阈值定义的相干钻研,否则在默认状况下,性能体现最差的 10-30%
的域将被归类为 ” 欠佳 ”。
总结
如果针对某一指标有相干的用户体验钻研,并且对文献中的数值范畴有正当共识,那么咱们会用这个范畴作为输出来领导咱们的阈值选取过程
在没有相干的用户体验钻研的状况下,会对满足不同指标候选阈值的真实世界页面进行评估,从而确定一个能带来良好用户体验的阈值。
在评估候选阈值时,发现这些规范有时会互相抵触。而用户行为指标又显示了行为的逐步变动,所以通常没有惟一 ” 正确 ” 的指标阈值,有时可能须要从多个正当的候选阈值中进行抉择。
示例—— LCP (Largest Contentful Paint) 阈值规范定制
一、体验品质
米勒和卡德的钻研将用户在失去注意力之前的等待时间形容为一个从大概 0.3
秒到 3
秒的范畴,也就表明咱们的LCP
“ 良好 ” 阈值应该在这个范畴内。此外,思考到目前的首次内容绘制 ” 良好 ” 阈值为1
秒,并且最大内容绘制通常产生在首次内容绘制之后,能够进一步将 LCP
候选阈值的范畴限度在 1
秒到 3
秒之间。
二、可实现性
利用 CrUX(Chrome User Experience Report)的数据,咱们能够确定网络上满足 LCP
候选 ” 良好 ” 阈值的域所占的百分比。
只有不到 10%
的域满足 1
秒阈值,但 1.5
秒到 3
秒之间的其余所有阈值也都满足咱们的要求,即至多有 10%
的域满足 ” 良好 ” 阈值,因而这些阈值依然是无效的候选值。
为了确保所选取的阈值对于优化良好的网站始终都可实现,Chrome
团队剖析了全网体现最出色的网站的 LCP
性能,从而确定哪些阈值对于这些网站是始终都可实现的。具体来说,咱们的指标是确定一个对于体现最出色的网站来说,始终能够在第 75
个百分位数实现的阈值。最终发现 1.5
秒和 2
秒的阈值并不是始终都能够实现的,而 2.5
秒的阈值是始终能够实现的。
为了确定 LCP
的 ” 欠佳 ” 阈值,咱们利用 CrUX
数据来确定大多数域可能满足的阈值:
在阈值为 4
秒的状况下,大概 26%
的手机端域和 19%
的桌面端域将被归类为欠佳。这些百分比落在 10-30%
的指标范畴内,因而,4
秒是可承受的 ” 欠佳 ” 阈值。
因而,得出结论,对于最大内容绘制来说,2.5
秒是一个正当的 ” 良好 ” 阈值,4
秒是一个正当的 ” 欠佳 ” 阈值。
指标分数
一旦 Lighthouse
收集了性能指标(大多数以毫秒为单位报告),它就会通过查看指标值在其 Lighthouse
评分散布上的地位,将每个原始指标值转换为 0
到100
之间的指标分数。评分散布是从 HTTP Archive
上实在网站性能数据的性能指标得出的对数正态分布。
例如,最大内容绘制 (LCP)
掂量用户何时感知到页面的最大内容可见。LCP
的指标值示意用户启动页面加载和页面出现其次要内容之间的持续时间。依据实在网站数据,体现最好的网站在大概 1,220
毫秒内渲染 LCP
,因而指标值映射为99
分。
HTTPArchive
数据的第 25
个百分位数变为 50
分(中值控制点),第 8
个百分位数变为90
分(良好 / 绿色控制点)。
指标的权重
性能分数是由指标的加权均匀计算出来的,一般来说,权重越高的指标,对性能的得分影响就越大。
为了使用户感知的性能处于一个绝对均衡的状态,权重会随着工夫而扭转。因为 Lighthouse
团队会定期的进行调研,依据用户的反馈来找出对用户感知的性能影响最大的因素,从而批改指标和权重。
下图为 Lighthouse 10
和 Lighthouse 8
的指标及权重变动比照:
如果想要理解更多能够查看:web 性能指标更新记录
结束语
咱们通过上述理解了 Lighthouse
性能得分计算背地的逻辑,没有去理解之前还不晓得 Chrome
团队为了些事件做了大量的工作。通过对用户行为和感知的大量钻研、理论的数据及用户反馈来定制和调整规范,有理有据,也更能反馈出理论的状况。只能说是真Niubility
。
参考资料
Lighthouse performance scoring
以用户为核心的性能指标
Web 指标
定义外围 Web 指标阈值