【第1952期】Lighthouse 6.0 新功能
前言
昨日的【第1951期】Lighthouse 测试内幕看了么？要是你还在关心自己开发的产品体验性能分析，这个工具不要错过。今日早读文章由@江边鸟授权分享。
江边鸟，坐标杭州，前阿里技术专家，前端混迹 8 年，轻微强迫症，喜收集整理，每天关注并分享泛前端领域行业资讯，欢迎一起学习交流。
正文从这开始~~
5月19日，Lighthouse 发布了 6.0 版本，带来了非常多的新特性，让我们一起来了解一下吧！
Lighthouse 是一个通过提供诊断报告和优化建议来帮助开发者提升站点用户体验的自动化站点审查工具。该功能可以在 Chrome 的开发者工具中使用（目前在 Audits 标签中，后续该标签页会直接改为 Lighthouse），也可以通过 Node 命令行工具或者浏览器插件的方式来使用。
最新的 6.0 版本目前可以通过 Node 命令行工具或者 Chrome Canary 版本中直接使用，Chrome 稳定版预计会在 7 月中旬的 v84 版本中集成。
通过以下命令可以马上使用 Node 命令行体验:
npm install -g lighthouselighthouse https://www.example.com --view
重要更新一览
新的衡量指标（主要是跟进 Core Web Vitals）
性能评分规则更新（配合更新一）
新的审查功能
Lighthouse 持续集成能力
开发者工具面板名称调整（品牌化）
移动端模拟
浏览器插件（简化实现，支持 Firefox）
指标预算
源代码定位
新的衡量指标
Lighthouse 6.0 的报告引入了 3 个新的指标，其中两个 LCP 和 CLS 来自 5 月份新发布的 Core Web Vitals 衡量体系，另一个是 TBT。
Largest Contentful Paint(LCP)
即主内容渲染时间，是前 FCP 指标的一个有力补充，LCP 分数低于 2.5 秒会被认为是“好”的体验。
Cumlative Layout Shift(CLS)
累计布局变更/累计视觉变更，用来计算非预期的 UI 界面变更对用户操作的影响，CLS分数低于 0.10 被认为是“好”的体验。
Total Blocking Time(TBT)
总阻塞时间，用来量化加载的响应能力，累积主线程被阻塞并会影响用户操作反馈的总时间。TBT 也与 Core Web Vitals 中的 FID 指标相关联（First Input Delay 首次交互延迟）。
性能评分规则更新
随着衡量指标的更新，评分规则也必然做出相应调整，具体如下图所示：
TTI 的权重从 33% 下降到 15%，这个主要基于 TTI 反馈的稳定性不够以及新的补充指标 TBT 的加入。
FCP 的权重从 23% 下降到 15%，主要是新的补充指标 LCP 的加入。
最大可能 FID 指标被废弃，不会再暂时到报告中，现在更推荐通过TBT 指标来衡量可交互性。
首次有效渲染（First Meaningful Paint）被废弃，这个数据太不稳定且因为 Chrome 内部渲染机制的关系而无法标准化。
首次 CPU 空闲 被废弃，因为这个指标和 TTI 指标重复性较高，而后续更推荐使用 TBT 和 TTI 指标来衡量交互性。
CLS 指标的权重目前还相对较低，在后续的主版本更新中可能会将其调高。
新的审查功能
Lighthouse 6.0 加入了一些非常有用的新审查功能：
未被使用的 JavaScript：这个功能实际在几年前就有了，但是当时性能非常差因此被默认关闭了，现在收集这方面数据的性能有了很大提升，因此重新默认开启。
可用性审查：Lighthouse 使用 axe-core 这个优秀的库来进行完整可用性方面的审查，目前已覆盖 8 个方面的内容。
Maskable icon 审查：Maskable icon 是一个能让 PWA 在不同的端和设备上都能更好展示的新图标类型，这个审查会分析应用的 manifest·josn 是否支持这个新类型。
Charset 声明审查：检查 HTML 中是否声明了 Charset meta 信息，以避免浏览器通过各种方式去判断以及规避可能的判断失误。
持续集成能力
去年 11 月份 Lighthouse 发布了 CI 的 Alpha 版本，CI 是一个能够在项目每次提交时都能跟踪并反馈项目的 Lighthouse 审查结果的持续集成功能。经过长时间的努力，Lighthouse CI 得以正式发布，目前已经支持集成到 Travis, Circle, GitLab, and Github Actions 等 CI 供应商中使用。
面板重新命名
将之前的 Audits 重命名为 Lighthouse，不用多说了！
移动端模拟
Lighthouse 秉承移动端优先的思想，因为移动端的体验问题更加突出并且容易被开发者忽略，这也是为什么 Lighthouse 会默认应用移动端模拟，模拟由以下 2 个方面构成：
模拟弱网和不同 CPU 状态（通过 Lantern 引擎）
设备屏幕大小模拟
浏览器插件支持
之前，Lighthouse 的 Chrome 插件能够很方便的在本地运行 Lighthouse，遗憾的是这非常难去继续维护。鉴于我们认为集成在开发者工具中的方式体验更好，我们决定简化浏览器插件的支持以释放忙碌的开发资源。
主要的简化是，现在插件使用 Google 的在线服务 Page Speed Insights API 来运行和不再是本地分析，这样的调整会对一些用户带来一些不利的影响，我们的建议是：
PageSpeed Insights 无法审查非公开的内部站点，如果是这个情况请使用开发者工具的 Lighthouse 面板或者 Node CLI 工具。
PageSpeed Insights 不保证使用最新版的 Lighthouse 发行版，一般更新会延后 1-2 周时间。
PageSpeed Insights 是一个 Google 的 API 服务，因此会需要用户持续同意 Google API 的服务条款，如果你无法做到，请使用开发者工具的 Lighthouse 面板或者 Node CLI 工具。
好消息是，我们释放出的资源可以更加聚焦到解决其它工程问题上。同时因为这一简化，我们也得以发布 Lighthouse 的 Firefox 版本扩展。
指标预算
Lighthouse 5.0 引入了性能预算能力，支持添加一个页面可以提供的不同资源类型的限制。Lighthouse 6.0 新增了指标预算能力，所以现在你可以给特定的衡量指标例如 FCP 设定一个门槛。
到目前为止，预算功能仅仅支持在 Node CLI 工具和 Lighthouse CI 两种方式下使用。
源代码定位
有一些 Lighthouse 检查发现的问题可以跟踪到某一行具体源代码，那么报告里面会给出相关的具体文件和行，点击相应链接可以直接将源代码在源码面板中打开并查看。
关于本文 作者：@江边鸟 原文：https://mp.weixin.qq.com/s/1Qs8Qhv0f0Hjt5VdwQ6xCA
https://web.dev/lighthouse-whats-new-6.0/
为你推荐
【第1441期】 Lighthouse的使用与Google的移动端最佳实践
欢迎自荐投稿，前端早读课等你来