什么是性能优化
一提到前端性能优化大家的本能反应：sprite 图合并 / 静态资源打包 /... ，那么针对网络这块是怎么进行性能优化的？
一般性的用户行为例子：
用户 => 促销页面 => 商品页面 => 下单流程 => 支付成功
首先用户访问促销活动页面，之后再到商品详情页面，然后再下单到支付成功。用户每进行一个步骤都是一次页面的访问，所以上面流程至少有 4 个及其以上的访问。一般性我们怎么来知道性能优化的标准呢？我们来看一下业内的一个关键词：
3秒 = 50% 离开
3 秒意味着可能有 50% 用户已经离开了，它其实定义了好与不好。例如：白屏时间超过了3秒，用户极有可能已经离开了。如果假设每个页面加载都超过 3 秒，那用户真正能留下来的概率就会是下面这样：
0.5 * 0.5 * ...
可以看出链路越长转化越差。
对于我们电商来说，性能优化如果能多降低 0.1 秒，能极大的提升销售的转化，对成本来说也会有很大的影响。另外，3 秒这个指标对访问入口也是有影响的。大于 3 秒的页面会影响到百度或者谷歌对网站的 SEO。流量可能会受一定影响。所以在流量和转化的一种双重夹击下面，性能优化成为一个必行之道。
性能优化的衡量标准
- Web 端（PC / Web App）：首屏时间、白屏时间、可交互时间、完全加载时间等。
- 移动端（Native App）：Crash 率、内存使用率、FPS（Frames Per Second，每秒传输帧数）、端到端响应时间等。
- 后端：响应时间（RT）、吞吐量（TPS）、并发数等。
下图是 Web 端的性能优化的木桶理论：
定位性能问题
通常的：
首屏时间 = DNS时间 + 建立连接时间 + 后端响应时间 + 网络传输时间 + 首屏页面渲染时间
上面的描述看起来会比较抽象，我们拿 Chrome 调试中的 Network 来看下具体的时序图是什么样。
上图中我们关心的指标通常有：
- Stalled（挂起）
- DNS Lookup（DNS 节点查询）
- TTFB（首字节的返回）
- Content Download（文档下载时间）
从图中可以看到 DNS 查询时间是 4.13ms，TTFB 是 2.08s，Content Download是 673.91ms。其中 TTFB 非常高，这可能是服务器、基础网络、CDN 出现问题。第二是 DNS Lookup 是 4.13ms，看起来还好一些，可能采用 CDN 就近策略，如果是单机部署的话这个值可能会高一些。Content Download 和网络、带宽及文本大小有关系。
看完时序图我们来看一下整体的一个汇总：
结合上面是单个时序图及多个请求的汇总图，我们来分析一下整体的时序图。
首先可以看到 index 请求发完后紧接着发了 9 个请求，其中 CSS 有3个，JS 有6个。有 3 个 JS 时间非常的长，这样情况我们可以调整代码打包的策略，将小的 JS 文件合并来减少请求的数量。一般建议小于 5k 的文件不要单独发一个 HTTP 请求。
执行性能优化
根据上面我们发现的性能问题，下面是执行了性能优化后的效果图。
均衡请求值的大小（其中蓝色的线是分布相对均匀）
控制合理的请求数量：单次5个（一般初次的请求数量 5 个就能满足了）
总结
最后总结一下性能优化。
性能优化更加像图中这样一个冰山。上面是网络层的优化，下面是代码层的优化。当然代码层优化是一个非常庞大的项目，它甚至会颠覆我们的技术选型。对于网络层我们都是有共性的，比如控制数量、控制请求的情况，不仅仅只是减少请求的数量甚至要均衡请求的大小。这是我们眼睛能看到的部分，这部分优化好之后其实也会对页面性能有一个质的飞跃。但是代码层因为每个项目都不一样选型，我们可以看下比如：部分动画我们是否可以采用CSS3的性能、插入DOM的时候是否可以批量插入。就像图中一样，代码层优化水也是很深的，需要大家在自己的项目中慢慢摸索。
以上就是关于Web端的性能优化，希望能帮到大家。
