前端开发少不了性能问题，好的性能检测方法/工具能够帮助我们快速定位和辅助解决问题。下面我们就chrome自带的性能检测工具Lighthouse / Audits进行详细介绍，旨在让大家能够更全面的了解它，并在实际开发中使用其帮助解决问题！
Lighthouse / Audits
Lighthouse 是一个开源的自动化工具，用于改进网络应用的质量。 您可以将其作为一个 Chrome 扩展程序运行，或从命令行运行。 您为 Lighthouse 提供一个您要审查的网址，它将针对此页面运行一连串的测试，然后生成一个有关页面性能的报告。
如何运行
运行lighthouse有两种方法：
-
1、作为 Chrome 扩展程序运行
打开chrome浏览器控制台，点击 工具栏「lighthouse」，选中相应参数，点击“generate report”生成报告即可；
-
2、作为命令行工具运行
命令行工具允许您将 Lighthouse 集成到持续集成系统
作为命令行工具运行
安装 Node，需要版本 5 或更高版本。
安装 Lighthouse 作为一个全局节点模块。
npm install -g lighthouse
针对一个页面运行 Lighthouse 审查。
lighthouse https://www.baidu.com/
传递 --help 标志以查看可用的输入和输出选项。
lighthouse --help
运行结果和分析和在chrome上运行一致，下面将会详细介绍！
chrome上运行
生成性能报告：
- Device
- Mobile：设置为Mobile将更改用户代理字符串并模拟移动视口。
- Desktop：设置为桌面几乎就是禁用移动更改。
- Categories
- Performance：性能
- Progressive Web App：渐进式web应用
- Best Practies：最佳实践
- Accessibility：无障碍
- SEO：Search Engine Optimization 的缩写，搜索引擎优化
Performance
网站性能整体得分（77），得分越高，网站性能越好；
Metrics
Metrics部分提供了站点性能的定量度量。每个指标都提供了对性能不同方面的洞察。例如，First Contentful Paint告诉你什么时候内容第一次被绘制到屏幕上，这是用户感知页面加载的一个重要里程碑，而Time to Interactive则标记页面显示为可以处理用户交互的时间点。
FCP（first contentful paint）
首次内容绘制的时间，首次有内容的绘制标志着第一个文本或图像被绘制的时间（从进入页面到首次有 DOM 内容绘制所用的时间），通常与白屏问题相关。
你的FCP分数是当前页面的FCP时间和真实网站的FCP时间的比较，基于HTTP Archive的数据。例如，执行99%的站点在大约1.2秒内渲染FCP。如果你的网站的FCP是1.2秒，你的FCP得分是99。
TTI（time to interactive）
页面可交互的时间，指页面变得完整所需的时间；一个页面被认为是完全交互式的条件:
- 页面显示有用的内容，这是由FCP衡量的;
- 事件处理程序为大多数可见页面元素注册（页面中大部分可见的元素已经注册了对应的监听事件（通常在 DOMContentLoaded 事件之后））;
- 并且该页面在50毫秒内响应用户交互。
SI（speed index）
速度指数，度量页面加载期间内容在视觉上显示的速度。Lighthouse首先捕捉页面在浏览器中加载的视频，并计算帧之间的视觉进展。然后使用Speedline Node.js模块生成速度索引得分；
这个指标反映了网页内容填充的速度。页面解析渲染过程中，资源的加载和主线程执行的任务会影响到速度指数的结果。
TBT（total blocking time）
阻塞总时间，测量的是 FCP 与 TTI 之间的时间间隔。这个指标反映了用户的交互是否能及时响应。 如果主线程执行了长任务会导致用户的交互无法及时响应。当主线执行的任务所需的时长超过 50ms，我们就认为这是一个长任务（long task）。假设在主线程上执行了一系列的任务，每个长任务的阻塞时间等于执行时间减去 50 ms，最后可以统计得到一个总的阻塞时间。例如，如果Lighthouse检测到一个70毫秒长的任务，阻塞部分将是20毫秒。
LCP（largest contentful paint）
最大内容绘制的时间，度量视口中最大的内容元素何时呈现到屏幕上。这近似于页面的主要内容对用户可见。
在 LCP 之前，lighthouse 还使用过 FMP（First Meaningful Paint，首次有意义内容绘制）指标。FMP 是根据布局对象（layout objects）变化最大的时刻来决定的。但是这个指标计算比较复杂，通常和具体的页面以及浏览器的实现相关，这也会导致计算不够准确。比如，用户在某个时刻绘制了大量的小图标。
CLS（cumulative layout shift）
累计布局位移（页面抖动），这个指标是通过比较单个元素在帧与帧之间的位置偏移来计算，计算公式是cls = impact fraction * distance fraction 。在以下例子中，文本块在两帧之间的 impact fraction 是红色框部分，占视窗 75%；distance fraction 是蓝色箭头的距离，占视窗 25%；那么最终的分数是 0.75 * 0.25 = 0.1875 。
为了提供良好的用户体验，站点应该努力使CLS分数达到0.1或更低。
Screenshots
在 Lighthouse 时间轴上，你可以看到在加载所有资源随时间的快照（Screenshots）；
百度PC首页
百度PC结果页（query=奥运）
掘金首页
快照在一定程度上可以很直观的展示出一个网页随时间加载的内容，可以初步对一个网页做出初略的评判；
也可以进入到控制栏“Performance”中查看具体情况进行分析：
Opportunities
给出可以加快页面加载速度的优化建议，结合程序自身情况酌情优化；
报告的 Opportunities 中可以看到影响评估的关键原因，和给出的一些建议，根据这些原因可以进行一些页面加载速度优化；
例如上图中给出的建议：
-
Reduce unused Javascript：减少未使用的JavaScript脚本加载，或者延迟加载直到需要它们时，以减少网络活动消耗的字节数；
Transfer Size：传输大小（实际传输大小）
Potential Savings： 潜在用到的大小（实际使用大小）
以第一个js为例：
使用率 = potential saving / transfer size => 245.4kb/342.7kb = 71.6%，也就是说该js在页面过程中只有71.6%的代码被使用了，还有28.4%的代码可以优化掉；
如何确定js文件中哪些代码是未被使用的？检查代码覆盖率
-
1、在控制台tab中进入network，找到all_async_search_3b2eb9f.js文件，并定位到原文件（source）；
-
2、如下图所示，找到covarage（覆盖）
-
3、查看当前js文件代码覆盖率和定位哪些代码片段是没有使用到的；
如图，计算出代码覆盖率为71.0%；源文件中红色部分代表使用到的代码片段，蓝色部分代表未被使用的代码片段；根据覆盖率和覆盖代码片段针对项目进行优化。
-
-
Properly size images：采用适当大小的图片
对于页面上的每个图像，Lighthouse 会将渲染图像的大小与实际图像的大小进行比较。渲染大小还考虑了设备像素比。
比如第三张图片：实际传输大小为56.5kib，建议中指出潜在使用大小为53.6kib，也就是说**5.17%**的体积是可以优化的；
按照修改建议优化：获取到的图片应该和前端元素大小一致，一是节省网络传输资源、二是避免对图片进行不同比例缩放处理；
在 lighthouse 的优化建议中，我们可以看到和 JavaScript 资源加载相关的建议有：
- Minify JavaScript：压缩资源体积（可以和前端工程化联系起来，比如编译打包时候使用gzip打包配合nginx）
- Remove duplicate modules in JavaScript bundles：删除JavaScript包中的重复模块（代码分割 & 公共提取 & 按需加载）
- Reduce Unused Css
- ···
Diagnostics
给出有关应用程序性能的更多信息，根据这些信息结合程序自身因素合理优化；
- Ensure text remains visible during webfont load：确保在网页字体加载过程中文本仍然可见
- Image elements do not have explicit
widthandheight：图像元素没有明确的宽度和高度 - Serve static assets with an efficient cache policy ：为静态资产提供高效的缓存策略
- Avoid an excessive DOM size：避免过大的DOM
- Avoid enormous network payloads ：避免巨大的网络负载
- ····
Passed audits
显示哪些衡量指标通过了审核，也就是当前指标已经很好了，说对于页面加载和性能的不产生负面影响；
- 延迟屏幕外图片加载；
- css压缩
- js压缩
- 减少未使用的css
- ···
