Lighthouse
谷歌开源的自动化分析工具
使用方法
使用
npm install -g lighthouse
lighthouse --locale=zh https://www.google.com // 默认移动端
lighthouse --locale=zh https://www.google.com --view --emulated-form-factor=desktop // 桌面端内部架构和工作原理
Lighthouse 的组成部分主要包括四个：驱动（Driver）、收集器（Gatherers）、审查器（Audits）和报告（Report），如图所示。
可以看到，Lighthouse 的具体工作过程为：
- 当网站页面开始加载之后，Lighthouse 会使用驱动（Driver）通过 Chrome DevTools Protocol 获取页面的性能数据；
- 驱动（Driver）获取到的数据会被收集器（Gatherers）进行收集，并输出被称为 Artifact 的结果；
- Artifact 会作为审查器（Audits）的输入，审查器会对其运行测试，然后分配通过/失败/得分的结果；
- 审查的结果给到报告（Report），对各个部分进行加权和统计得到面向用户的报告（如最佳实践），并将该报告渲染给用户。
如果你希望短时间内对你的网站进行较全面的评估，可以使用 Lighthouse 来跑一下分数，确定大致的优化方向。但 Lighthouse 不能用于运行时的性能分析，也无法给到最佳实践以外更多的数据和建议。
而 Performance 面板则可以弥补 LightHouse 的不足。
网站性能衡量标准
网站性能衡量标准
准确衡量网站的性能 根据 Google 在 web.dev 上公布的数据，他们认为以用户为中心的性能指标，应该能回答以下四个问题 ：
web.dev 是 Google Developer 提供的开发者社区，里面主要提到了一下列出的诸多类型的数据 指标。
- 是否发生？ 导航是否成功启动？服务器是否有响应？
- 是否有用？ 是否已渲染可以与用户互动的足够内容？
- 是否可用？ 用户可以与页面交互，还是页面仍在忙于加载？
- 是否令人愉快？ 交互是否顺畅而自然，没有滞后和卡顿
是否发生
当用户访问一个网站的时候，关心的第一个问题永远是“是否发生”——浏览器是否成功地把我的请求发送出去，而服务器是否已经知道并开始处理我的请求。
- TTFB (Time to First Byte) 首字节到达的时间点。
- FP (First Paint) 首次绘制，标记浏览器渲染任何在视觉上不同于导航前屏幕内容的时间点。
- FCP First Contentful Paint 首次内容绘制，
这是一副 FCP 和 LCP 之间的示例图
是否有用
当用户确定自己的请求发生了后，就会开始关心第二个问题：“是否有用？” 例如，用户在使用天气应用，在确定页面有反应了后，就开始关心，什么时候能展现有用的内容，从而 得知今天的天气。
LCP Largest Contentful Paint 最大内容绘制时间，计算从页面开始加载到用户与页面发生交互（点击，滚动）这段时间内，最大元素绘制的时间，该时间会随着页面渲染变化而变化，因为页面中的最大元素在渲染过程中可能会发生改 变。
SI Speed Index 速度指标，填充页面内容的速度，取开始加载到最后完成渲染，每一时刻页面未完成度的积分。
是否可用
在用户得到了有用的信息后，用户就会基于得到的信息作出反应，这就是页面“是否可用？”例如看到了 新闻后，想要评论。TTI、FID、TBT 就是回答这些问题的指标。
- ** TTI (Time to Interactive)**
- TBT Total Blocking Time 总共阻塞时间，计算的是从 FCP 到 TTI 之间，主线程阻塞的总时间。阻塞时间是指单次任务占用主线程超过 50 ms 的部分。
- FID (First Input Delay) 首次输入延迟，指用户首次输入到页面响应的时间。我们都知道第一印象的重要性，网站亦是如此。首次输入延迟会成为用户对网站很重要的第一印象，决定用户有可能成为忠实用户或者弃之而去。值得注意的是，FID 仅关注用户离散的操作，如点击，轻击，按键等，其他交互如滚动和缩放，并不是 FID 关注的，因为通常浏览器会用一个单独的线程来处理它们。
是否令人愉快
使用是否流畅，有没有发生预料外的视觉偏移。
- CLS (Cumulative Layout Shift) 累计布局偏移。测量在页面的整个生命周期中发生的每个意外的样式移动所造成的布局偏移分数的总和测试视觉稳定性上的体验，有多少内容发生了意外的偏移。
其他数据
- 静态资源及 API 请求成功率。通常是通过 window. Performance. GetEntries ( ) 来获取相关信息
- Page Load，页面完全加载时间。通常通过记录 window.performance.timing 中的 loadEventStart 与 fetchStart 的时间差来完成。
- 在性能监控中有一个概念叫 TP（Top Percentile），比如 TP50、TP90、TP99 和 TP999 等指标，指高于 50%、90%、99% 等百分线的情况。
数据测量
指向原始笔记的链接
网站性能衡量标准
网站性能衡量标准
准确衡量网站的性能 根据 Google 在 web.dev 上公布的数据，他们认为以用户为中心的性能指标，应该能回答以下四个问题 ：
web.dev 是 Google Developer 提供的开发者社区，里面主要提到了一下列出的诸多类型的数据 指标。
- 是否发生？ 导航是否成功启动？服务器是否有响应？
- 是否有用？ 是否已渲染可以与用户互动的足够内容？
- 是否可用？ 用户可以与页面交互，还是页面仍在忙于加载？
- 是否令人愉快？ 交互是否顺畅而自然，没有滞后和卡顿
是否发生
当用户访问一个网站的时候，关心的第一个问题永远是“是否发生”——浏览器是否成功地把我的请求发送出去，而服务器是否已经知道并开始处理我的请求。
- TTFB (Time to First Byte) 首字节到达的时间点。
- FP (First Paint) 首次绘制，标记浏览器渲染任何在视觉上不同于导航前屏幕内容的时间点。
- FCP First Contentful Paint 首次内容绘制，
这是一副 FCP 和 LCP 之间的示例图
是否有用
当用户确定自己的请求发生了后，就会开始关心第二个问题：“是否有用？” 例如，用户在使用天气应用，在确定页面有反应了后，就开始关心，什么时候能展现有用的内容，从而 得知今天的天气。
LCP Largest Contentful Paint 最大内容绘制时间，计算从页面开始加载到用户与页面发生交互（点击，滚动）这段时间内，最大元素绘制的时间，该时间会随着页面渲染变化而变化，因为页面中的最大元素在渲染过程中可能会发生改 变。
SI Speed Index 速度指标，填充页面内容的速度，取开始加载到最后完成渲染，每一时刻页面未完成度的积分。
是否可用
在用户得到了有用的信息后，用户就会基于得到的信息作出反应，这就是页面“是否可用？”例如看到了 新闻后，想要评论。TTI、FID、TBT 就是回答这些问题的指标。
- ** TTI (Time to Interactive)**
- TBT Total Blocking Time 总共阻塞时间，计算的是从 FCP 到 TTI 之间，主线程阻塞的总时间。阻塞时间是指单次任务占用主线程超过 50 ms 的部分。
- FID (First Input Delay) 首次输入延迟，指用户首次输入到页面响应的时间。我们都知道第一印象的重要性，网站亦是如此。首次输入延迟会成为用户对网站很重要的第一印象，决定用户有可能成为忠实用户或者弃之而去。值得注意的是，FID 仅关注用户离散的操作，如点击，轻击，按键等，其他交互如滚动和缩放，并不是 FID 关注的，因为通常浏览器会用一个单独的线程来处理它们。
是否令人愉快
使用是否流畅，有没有发生预料外的视觉偏移。
- CLS (Cumulative Layout Shift) 累计布局偏移。测量在页面的整个生命周期中发生的每个意外的样式移动所造成的布局偏移分数的总和测试视觉稳定性上的体验，有多少内容发生了意外的偏移。
其他数据
- 静态资源及 API 请求成功率。通常是通过 window. Performance. GetEntries ( ) 来获取相关信息
- Page Load，页面完全加载时间。通常通过记录 window.performance.timing 中的 loadEventStart 与 fetchStart 的时间差来完成。
- 在性能监控中有一个概念叫 TP（Top Percentile），比如 TP50、TP90、TP99 和 TP999 等指标，指高于 50%、90%、99% 等百分线的情况。
数据测量
指向原始笔记的链接强烈建议用 lighthouse 跑一遍自己的网站，里面的链接才是精华，另外可以看看 Googel 的开发者网站，要不是我不懂英文就看完了。