性能优化第一步：性能瓶颈分析

将精力放到关键性的指标之上
一般咱们讲的性能优化就是缩短用户可见区域的内容的加载时间，通常来讲就是咱们的首屏。由于它和用户体验息息相关，而不是只关注于整个页面的加载时间（例如 onLoad 和 DOMContentLoaded 时间）。固然若是你网站确实很庞大，你也能够将精力放到减小白屏时间上，由于一个好的 loading 动画能让用户在内心上缩短网站首屏时间。下面就给出这两个指标的定义。

白屏时间：指从浏览器开始跳转到第一次有内容渲染的时间（一般状况下，这一段时间用户的浏览器都是白色的，因此叫作白屏时间）。

首屏时间：指从浏览器开始跳转到用户可见区域的内容渲染完毕的时间。

Audits 使用

Audits 是 chrome 开发者工具中自带的专门用于识别影响站点性能、可访问性和用户体验的常见问题。

使用 chrome 浏览器隐身模式打开你要测量的页面（避免插件的干扰），而后打开开发者工具，找到 Audits ，点击它就进入了 Audits 页面。

图 1 ：Audits 设置界面

选项说明

Device: 选择你要测量的网站是移动端仍是桌面端

mobile: 移动端
desktop: 桌面端
Audits: 选择你要测量的内容

Performance: 网站性能
Progressive Web App: 渐进式支持
Best practices: 最佳实践
Accessibility: 可访问性
SEO： SEO 支持
Throttling: 设置网速和 CPU 速度

模拟 fast-3g 网速， 1/4 倍 CPU 速度
真实 fast-3g 网速，1/4 倍 CPU 速度
不节流
Clear storage: 清除缓存

Run audits: 开始测量

测试结果分析

如下测试结果环境

测试网页地址：https://www.xiguacity.cn/fe-p...

测试选项：mobile, 真实 fast-3g 网速，1/4 倍 CPU 速度, Clear storage

点击 Run audtis 后，稍等片刻后咱们就能够获得以下的测量结果页面：

图 2 ：Audits 结果页面

结果页指标说明

Metrics: 关键性指标

First Contentful Paint: 首次内容渲染时间（第一个文本或图像绘制的时间）
First Meaningful Paint:页面主要内容出如今屏幕上的时间点
Speed Index: 首屏时间
First CPU Idle : CPU 第一次空闲的时间
Time to Interactive: 第一次可交互的时间
Estimated Input Latency: 估计的输入延迟 (估计您的应用程序在页面加载最繁忙的 5s 窗口中响应用户输入所需的时间，以毫秒为单位若是您的延迟超过50毫秒，用户可能会认为您的应用程序是卡顿的)
Opportunities: 能够改进的地方

例举出了你能够作的优化来加快页面加载速度，

Diagnostics: 诊断

有关应用程序性能的更多信息

好的，咱们如今已经对咱们网站的性能状况有了一个初步的了解，白屏时间： First Contentful Paint 2.3s，首屏时间： Speed Index 7.1s。并且咱们在 Opportunities 也获得了一些建议好比 Preload 关键请求，使用下一代图片格式及有效的编码图像。可是只有这些数据仍是咱们仍是一脸懵比，咱们如今已经知道咱们白屏和首屏很慢，可是关键问题出在哪里？咱们怎么去改进仍是不太清除。下面就会介绍怎么用 Performance 对网站性能进行详细分析。

Performance 使用

在图 2 中 Time to Interactive 指标下面与有个按钮 View Trace，点击它就能够进入到 Performance 看板，在这里能够对网站的详细性能状况进行分析。
Performance 能够搭配 Audits 使用也能够单独使用

图3: performance 测试结果页面

也许你第一次进入这个页面面对这么多数据有点手足无措，可是咱们如今只用关心咱们最关心的数据——Network（图中间的部分），它还原了咱们的页面载入过程当中的网路请求时序图。下面详细解释。

Network 详解

坐标轴

图的横轴表示时间，纵轴堆叠在一块儿的请求代表他们是同一时间发起的。

请求方块颜色

蓝色：html
紫色：css
黄色：js
绿色：img
每个颜色又分为浅色部分和深色部分，其中浅色部分表示从发送请求到第一个字节返回的时间（TTFB: Time To First Byte），深色的部分表示内容下载的时间。

**请求方块左右的两侧的灰色实线
**
左侧：请求发送前等待的时间
右侧：请求发送后等待主线程处理的时间
好的咱们如今对 Network 看板有了一个大体的了解，下面就结合 Network 来对性能瓶颈进行详细分析。

结合 Network 对性能进行分析

咱们按照请求发起的时间将请求大体划分为 7 步，从下图能够看出走完前 6 步后才开始请求内容图片，对应到项目里面就是 react 第一次渲染出页面内容，而这个时间都已经到了第 5s。

图4: network 请求时序图

因此根据上图咱们至少找到两处瓶颈

串联请求太多，从第一步到第六步
图片太大，请求时间太长
找到了瓶颈咱们就有了方向来优化它，咱们决定先解决第一个瓶颈串联请求太多的问题，为了解决它咱们须要弄清除这六步到底在作什么。

其中第 3 步你们可能不太清楚这里是由于项目采用了单页面入口模式，而后用了 react-router 去作前端路由加以前端路由的页面又作了懒加载，因此第三步就是前端路由命中咱们想要的页面后去拉取这个页面所需的资源（js，css）。第 4， 5， 6 你们均可以简单理解为去请求服务器 API 而后等待服务器数据返回。因此根据上面的分析，咱们初步就能够得出如下几项优化措施

去掉路由懒加载，项目改为多页面模式，直接干掉第 3 步。
在服务端去调用 5 和 6 步 API 直接生成静态页面，干掉第 5 和 6 步。
使用下一代图片格式（webp）优化图片大小，缩短第7步。
使用图片懒加载，优先加载首屏图片。
优化后的 Network 时序图

图5: 优化后的 network 请求时序图

能够看见咱们将步数压缩到了4步

html 请求
html 中连接的资源，可是与以前的不一样的是，作了静态化模版后首屏的图片也会在这里发起请求
主要是进行微信受权
微信受权后再加载须要身份认证的组件
特别说明一下，这个页面受限与微信受权的影响，仍是要分 4 步，理想状况下，咱们能够是能够压缩到 2 步。这样在 fast-3g 网速下首屏时间就能进 2s 了。

结语

自此，对网站性能瓶颈的分析就结束了，详细的手段将在下一节进行介绍。本文只是用一个例子来介绍了如何对网页性能瓶颈进行分析。更重要的是但愿你们掌握对性能分析工具 Audits 和 Performance 的使用，在平常工做中触类旁通，养成注重网页性能的良好习惯。