前端性能 ​

• 正常访问 根据地址是否能正确访问到网页？服务器请求是否正常响应？
• 内容展示 页面是否渲染了用户可用的、关心的内容？
• 正常交互 页面是否可以正常响应用户的交互操作？
• 响应流畅 用户的交互响应是否流畅自然？

Lighthouse 性能分析指标 ​

lighthouse 是 Google Chrome 推出的一款开源自动化工具，它可以搜集多个现代网页性能指标，分析 Web 应用的性能并生成报告，为开发人员进行性能优化的提供了参考方向。

• 在 Chrome DevTools 中使用
• 在 Node 命令行工具中使用

Lighthouse 提供了 6 个性能指标：FCP、SI、LCP、TTI、TBT 和 CLS； 权重分别是 15%，15%，25%，15%，25% 和 5%。Lighthouse 会根据权重计算得到一个分数值。 ​

FCP（First Contentful Paint）首次内容绘制。 ​

它统计的是从进入页面到首次有 DOM 内容绘制所用的时间。这里的 DOM 内容指的是文本、图片、非空的 canvas 或者 SVG。我们也可以在 Performance 面板看到这个指标。

FCP 和我们常说的白屏问题相关，它记录了页面首次绘制内容的时间。一个常见的影响这个指标的问题是：FOIT（flash of invisible text，不可见文本闪烁问题），即网页使用了体积较大的外部字体库，导致在加载字体资源完成之前字体都不可见。可以通过 font-display API 来控制字体的展示来解决。

但值得注意的是，页面首次绘制的内容可能不是有意义的。比如页面绘制了一个占位的 loading 图片，这通常不是用户所关心的内容。

LCP（Largest Contentful Paint）最大内容绘制 ​

它统计的是从页面开始加载到视窗内最大内容绘制的所需时间，这里的内容指文本、图片、视频、非空的 canvas 或者 SVG 等。

在 LCP 之前，lighthouse 还使用过 FMP（First Meaningful Paint，首次有意义内容绘制）指标。FMP 是根据布局对象（layout objects）变化最大的时刻来决定的。但是这个指标计算比较复杂，通常和具体的页面以及浏览器的实现相关，这也会导致计算不够准确。比如，用户在某个时刻绘制了大量的小图标。

Simpler is better！用户感知网页的加载速度以及当前的可用性，可以简单地用最大绘制的元素来测量。

SI（Speed Index）速度指数 ​

Lighthouse 会在页面加载过程中捕获视频，并通过 speedline 计算视频中帧与帧之间视觉变化的进度，这个指标反映了网页内容填充的速度。页面解析渲染过程中，资源的加载和主线程执行的任务会影响到速度指数的结果。 ​

CLS（Cumulative Layout Shift）累计布局偏移 ​

这个指标是通过比较单个元素在帧与帧之间的位置偏移来计算，计算公式是 cls = impact fraction * distance fraction 。

TTI（Time To Interactive）页面可交互的时间 ​

这个时间的确定需要同时满足以下几个条件：

• 页面开始绘制内容，即 FCP 指标开始之后
• 用户的交互可以及时响应, 即页面中大部分可见的元素已经注册了对应的监听事件（通常在 DOMContentLoaded 事件之后）
• 在 TTI 之后持续 5 秒的时间内无长任务执行（没有超过 50 ms 的执行任务 & 没有超过 2 个 GET 请求）

TBT（Total Blocking Time）阻塞总时间 ​

TBT 测量的是 FCP 与 TTI 之间的时间间隔。这个指标反映了用户的交互是否能及时响应。 如果主线程执行了长任务会导致用户的输入无法及时响应。当主线执行的任务所需的时长超过 50ms，我们就认为这是一个长任务（long task）。假设在主线程上执行了一系列的任务，每个长任务的阻塞时间等于执行时间减去 50 ms，最后可以统计得到一个总的阻塞时间。

其他性能分析指标 ​

Chrome Coverage 代码覆盖率功能 ​

开发者面板右上角 》 自定义和控制 DevTools 》 更多工具 more tools 》 覆盖率 Coverage

Coverage 录制结果表格展示了录制过程中加载的所有 JS 和 CSS 文件，以及每个文件的大小、运行时覆盖率。 每个文件条形图的红色部分是未使用的字节，绿色部分是已用字节。 Coverage 底部信息显示的是汇总的使用覆盖率信息。 单击单个静态资源能将其在 Sources 面板中打开，代码行号的左边红色表示未使用，绿色表示已使用。

Coverage 分析后的改动方向：除移死代码、懒加载代码。

webpack-bundle-analyzer ​

在 webpack 项目里，使用 webpack 的插件 webpack-bundle-analyzer 来分析， 打包后会生成如下的报告，我们可以查看模块打包的情况， 还可以切换 Stat / Parsed / Gizzped 来查看开启压缩后代码体积的变化。

性能优化方向： ​

• 开发阶段

  • 代码去重 & 模块化
  • 图片懒加载 & 预加载
  • 响应式图片大小
  • 图片格式优化 WebP
  • 带字体显示的字体：预装可选
  • 预加载最大内容绘画图像
  • 高性能的动画
  • 避免执行长任务
  • 字体图标代替图片图标
  • 慎用全局变量
  • 减少重绘回流
  • 节流、防抖
  • 少用闭包、减少内存泄漏

• 构建打包阶段

  • Code Splitting 代码分割：多入口、抽离公共代码、动态 import 加载
  • Tree-Shaking
  • 代码压缩 minimize
  • 静态资源整合和压缩
  • 按需加载

• 网络请求阶段

  • 减少 HTTP 请求或者多服务器请求负载均衡
  • 静态资源单独域名
  • 使用 HTTP/2
  • 静态资源 CDN 加速
  • 使用 gzip 压缩
  • 做服务端渲染（SSR）
  • 使用 pre-* 预解析&预下载&预处理&预渲染
  • 合理的 HTTP 缓存策略
  • 合理的加载顺序/策略（延迟加载/预先加载）
  • 避免巨大的网络负载
  • 考虑脚本加载的顺序

参考资料 ​

• 使用 Lighthouse 分析前端性能
• chrome coverage
• chrome lighthouse