将精力放到关键性的指标之上
通常我们讲的性能优化就是缩短用户可见区域的内容的加载时间，一般来说就是我们的首屏。因为它和用户体验息息相关，而不是只关注于整个页面的加载时间（例如 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 的使用，在日常工作中举一反三，养成注重网页性能的良好习惯。