https://github.com/GoogleChrome/lighthouse

Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.

性能优化的一些建议 https://web.dev/fast/ ， https://web.dev/lighthouse-performance/ Lighthouse 估分模型 https://web.dev/performance-scoring/?utm_source=lighthouse&utm_medium=cli

以用户为中心的性能

image.png

Lighthouse报告展示

image.png
image.png

工具的安装与使用

  1. Chrome 浏览器中的开发者工具选项中已自带有

    这是通常我们所用的模式

  2. Node CLI

    与第一种方式对比，很容易发现同一个站点的测试报告数据差异特别大。简单的查阅了网络信息，此种模式可能是不适用于国内站点的

  1. # 安装
  2. $ npm install -g lighthouse
  4. # 测试执行
  5. $ lighthouse --view {url}
  7. # 具体支持的命令参数可查看帮助手册
  1. 作为 Node 模块引入工程(可作为 trace)

    https://github.com/GoogleChrome/lighthouse/blob/master/docs/readme.md#using-programmatically https://github.com/GoogleChrome/lighthouse/blob/master/docs/configuration.md

有参考意义的问题

人类眨眼一次所耗的时间是多长？
—— 答案是：200ms 左右

度量指标(Metrics)

长久以来，网络性能都是通过[load](https://developer.mozilla.org/docs/Web/API/Window/load_event)事件进行测量的。然而，尽管load是页面生命周期中明确定义的时刻，但该时刻并不一定与用户在意的任何方面相对应。

image.png
image.png

TTFB

https://web.dev/ttfb/ Time to First Byte 到达服务器的首字节

它很容易让我们认为无法做出优化，“毕竟请求已经往服务端发出了，就看网速的缘分”。其实不然，这个是最具综合因素影响的指标，除了网速本身 比如请求发出的内容控制(术语上可以称为 payloads “载荷”)，比如缓存静态资源、分段请求等，又或者请求时机(比如预加载、懒加载)等，又或者做 CDN 加速、采用 HTTP2/3 等，也可能的是服务端需要做优化

image.png
image.png
image.png

FCP

First Contentful Paint 首个内容绘制 测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间

在古老的 web 前端质量度量中，往往以该指标的达成时间作为了核心指标 😶

image.png

* LCP

Largest contentful paint 最大内容绘制 测量页面从开始加载到最大文本块或图像元素在屏幕上完成渲染的时间 https://web.dev/i18n/zh/lcp/

我们都清楚的知道，以用户体验为中心的指标，遵循中 2(3)/5/8 的原则（数字的单位是s秒）.
image.png

在我过往经历过的成功案例中，该类优化的核心是两个点

  • 获取到屏幕的高宽，并与屏内展示内容的高宽做比较，通过计算出每屏加载多少内容来进行分页(段)处理
  • “一头一尾”的处理。“头”是预加载，即在启动过程中预加载第一段；“尾”则是懒加载，即在前一段加载渲染完成时，接着加载第二段。当用户浏览(翻页或滚动)时，视觉上是连续的，少有被迫等待的体感

    * FID

    First input delay 首次输入延迟 测量从用户第一次与网站交互直到浏览器实际能够对交互做出响应所经过的时间

image.png
image.png

* TTI

Time to Interactive 可交互时间 测量页面从开始加载到视觉上完成渲染、初始脚本(如有)完成加载，并能够快速、可靠地响应用户输入所需的时间

https://web.dev/i18n/zh/tti/

服务器端渲染 (SSR) 等技术可能会导致页面看似具备交互性（即，链接和按钮在屏幕上可见），但实际上并不能进行交互，因为主线程被阻塞或是因为控制这些元素的 JavaScript 代码尚未完成加载 对于此，要做的是将 FCP 和 TTI 之间的差值降至最低。如果两者在某些情况下确实存在明显差异，则通过视觉交互(比如提示)清楚表明页面上的组件还无法进行交互

image.png

TBT

Total blocking time 总阻塞时间 测试 FCP 与 TTI 之间的总时间。这期间，主线程被阻塞的时间过长，无法作出输入响应

https://web.dev/i18n/zh/tbt/ 该项指标有助于量化在页面交互性变为可靠前，不可交互程度的严重性，较低的 TBT 有助于确保页面的可用性

image.png

CLS

Cumulative layout shift 累积布局偏移 测量页面在开始加载和其生命周期状态变为隐藏期间发生的所有意外布局偏移的累积分数 https://web.dev/i18n/zh/cls/

在构建UI自动化测试的 demo 时，就遇到了这样的情况——在设计器中拖拽组件并释放，然后设置组件属性时，组件被重新渲染到了原点坐标 😶
image.png

Speed Index

速度指数 测量页面加载期间内容的视觉显示速度 https://web.dev/speed-index/ 提到了其算法与原理，定义的速度指数指标，优化的方式方法 https://github.com/WPO-Foundation/webpagetest-docs/blob/main/src/metrics/SpeedIndex.md

图片引自 https://blog.csdn.net/weixin_37883657/article/details/117525844 （特别感谢）image.png