BruceBlog性能优化专项学习
性能优化概述
开发困扰：
- 对页面性能不够重视，导致用户体验不佳，出现崩溃、卡顿、白屏问题。
- 不懂怎么分析页面性能瓶颈，无法进行针对性优化。
- 不理解优化的原理，只能照搬资料，优化效果不佳，甚至是反效果。
性能优化对用户体验非常重要，对转化率提升具有重要意义，对业务提升具有重要价值，特别是低端机型。
系统掌握前端性能优化，为自己个人增值，提升自己开发页面的性能体验，提升自己负责业务的业务量。
性能指标
性能指标概述
性能是用户在页面加载和运行时的直观体验（感觉），但我们优化的时候，不能用感觉去衡量性能怎么样，必须要用可衡量的值去判断性能优化结果，这就是性能的指标。了解性能指标，可以给优化过程制定明确目标。
常见性能指标如下：
首屏时间（最常用）：页面以多快的速度加载和渲染元素到页面上。
加载后的响应时间：页面加载和执行 JS 代码后多久能响应用户交互。
视觉稳定时间：页面什么时候变稳定，变得不影响观看交互。
首屏时间
首屏时间最大程度决定了网页的用户体验，是性能中最关注的部分，首屏时间使用哪个指标衡量，目前没有固定的标准。
目前首屏时间常用的指标主要有 FMP 和 LCP。
| 指标 | 含义 | 问题 |
|---|---|---|
| FP:First Paint，首次绘制 | 白屏时间，它代表浏览器第一次向屏幕传输像素的时间，也就是页面在屏幕上首次发生视觉变化的时间 | 像素的改变不够直观，代表首屏时间过于单薄，不是用户关注的内容 |
| FCP:First Contentful Paint，首次内容绘制 | 测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间 | 内容仅包括文本、图像（包括背景图像）、svg 元素或非白色的 canvas 元素，不一定是用户关注的真正内容。背景、loading |
| LCP:Largest Contentful Paint，最大内容绘制 | 测量页面开始加载到最大文本块内容或图片显示在页面中的时间 | 存在兼容性问题，低版本安卓和IOS不支持 |
| FMP:First Meaningful Paint，首次有意义绘制 | 首次有意义的绘制，是页面主要内容出现在屏幕上的时间 | 什么是主要内容？目前尚无标准化的定义 |
| DOMContentLoaded | 当初始的 HTML 文档被完全加载和解析完成之后，DOMContentLoaded 事件被触发，而无需等待样式表、图像和子框架的完全加载 | SPA 页面，index.html 加载完成后，DOMContentLoaded 即被触，但页面空白 |
| OnLoad | 当整个页面及所有依赖资源如样式表和图片都已完成加载时，将触发load事件 | SPA 页面，index.html 加载完成后，OnLoad即被触发，但页面空白 |
优化目标
性能指标目标：FMP或者LCP 指标在 P95 分位上达到 3.5S。也就是前 95% 的用户首屏时间需要在 3.5S 内。
从 2 个维度进行提升：
- 「真的快」：可以客观衡量的指标，像首屏时间、网页访问时间、交互响应时间、跳转页面时间。
- 「觉得快」：用户主观感知的性能，通过视觉引导等手段转移用户对等待时间的关注。
性能优化工具
每个业务工程都有其不同的地方，需要针对分析和优化。学会怎么分析性能瓶颈，这是性能优化的前提。从复杂系统中找到性能问题的关键所在，这是性能优化的第一步。
分析工具：一般都是本地对性能某一方面进行分析，比如打包情况、资源大小、请求顺序、JS执行情况等。
合成监控：一种模拟网页加载或者脚本运行来测量性能指标的方式，输出网页性能报告。这种方式的价值在于提前发现可能存在的性能问题，不依赖于用户上报。用于在本地开发时提前发现一些性能问题。单个样本，不全面。
真实用户监控：记录用户真实操作的一种被动监控，它的特点是记录真实用户在网页交互中的性能数据。反映用户使用的真实情况，和用户设备、网速、环境等息息相关。群体样本，客观全面。
Chrome Network
Chrome 浏览器 F12 开发者工具中 Network 标签。
Chrome Network：显示网络资源加载耗时及顺序，能看到资源的名称、状态、使用的协议(http1/http2)、资源类型、资源大小、资源时间线等情况。
可以发现一些常见问题：某个 js 文件过大，成为性能瓶颈；接口请求存在依赖关系，串行请求；存在一些很琐碎的小文件，几百B的 js 文件。
Chrome Performance
Chrome 浏览器 F12 开发者工具中 Performance 标签，可以观察页面渲染表现及JS执行情况。
请求瀑布图：瀑布图的横轴是时间轴，瀑布图上有很多五颜六色的色块，不同颜色代表不同的资源。通过分析资源的顺序、请求分布和请求详情，得出一些优化结论。
主线程火焰图：分析具体函数耗时，面板中会有很多Task，如果是Long Task右上角会被标红，可选择放大查看具体耗时点。
详情饼图：用于展示各种类型任务的耗时占比，可以看出下载、执行、渲染、空闲等时间。
在左侧的 insights 面板里面，可以看到瓶颈和优化措施。
webpack-bunld-analyzer
以视图的方式显示 webpack 输出文件的大小，可视化帮我们分析打包体积和包的组成，让我们可以用针对性的分包合包构建策略优化我们的模块bundle。
分析步骤：
查看哪个包比较大。
分析包的组成，查看组成是否合理，是否能够缩小体积。
比如：vendor 把大部分 node_modules 的库都打包进来，体积太大，首屏不一定使用的也打包进来，任何依赖的改变也容易改变 hash 值，影响缓存，对首屏影响很大。
Lighthouse
Lighthouse：是谷歌开发的合成测试工具(自动集成在devtools中) ，它既可以作为浏览器插件运行，也可以作为 cli 脚本，甚至以程序化的方式运行在你的 Node.js 代码中。它通过一系列的规则来对网页进行评估分析，最终给出一份评估报告。
利用LightHouse进行合理的页面性能优化，看这一篇就够了！
ARMS 监控工具
ARMS监控工具：ARMS前端监控专注于对Web场景、Weex场景和小程序场景的监控，从页面打开速度（测速）、页面稳定性（JS诊断错误）和外部服务调用成功率（API）这三个方面监测Web和小程序页面的健康度。
性能优化概述
页面打开，是浏览器通过网络从服务器请求具有一定大小的资源，并且展示的过程。
性能优化可以归结为 3 类优化方向：
请求越快：加快请求。
资源越小：减小内容。
越早展示：提前渲染。