前端性能优化

序

  开题之前，思考以下三个性能比较：

for循环 和 while循环 哪个更快？
Math.floor 是否比 |0 更好?
多个 if-else 是否要用 switch-case 替代?

  前端发展至此，前端性能随之变成了一个很有意思的话题。从入门级别的初级工程师，到高级别的专家，都离不开性能问题。那么前端性能该如何理解呢？

总论

  前端时间学习前淘宝前端总负责人winter的课程，受益颇深。前面三个性能比较的例子，在社区或者论坛中大家对此的讨论从未断过，也乐此不疲。但是，它们出了让你写代码的时候纠结之外，毫无意义。
  比如，在写业务的时候，某一个功能模块有数据操作，千方百计的将某个循环操作优化了，可能执行效率提高了一倍。可是在整体来看，页面打开速度一样，用户也没有任何良好反馈，甚至测试都毫无察觉。因此，性能优化不能局限于局部代码。用大佬winter的话来讲，就是一切没有profiling的性能都是耍流氓。凡是真正有价值的性能优化，必定是从端到端的业务场景建立体系来考虑的。

流程分析

  那么我们从何入手，又该怎样考虑和执行呢？总结如下：

• 现状评估和建立指标
• 技术方案
• 执行
• 结果评估和监控

1. 现状评估

  此处，要解决的问题有两个：

1. 从用户体验来讲，什么样的性能指标能更好的评估产品的体验？
2. 对公司来说，什么样的指标会影响到公司业务价值？

  性能问题大致分为三个层次：

• 页面加载；
• 动画与操作；
• 内存，电耗；

2. 建立指标

  从这三个方面来看，如果一个页面在经历了几秒的白屏才打开，那注定用户流失率会极其高。而用户流失率是公司所注重的，因此页面加载则是重中之重。因此，需要大量评测页面加载时常对用户的影响。大量数据表示，加载时间在1s以内，差别都不大。因此首要就是正常网络状况下，加载时长要优化至1s以内。但是会碰到一个新的问题，就是少数极端网络用户（如2g网络）加载时间会极长，在统计后，会极大的拉低平均加载时长，从而影响整体的指标。因此，指标不能反应大多数的用户体验。因此，他们团队提出——秒开率：一秒之内能打开的用户占总用户的比重。

3. 技术方案

  有了目标，便需要以技术手段去解决问题了。在课程中，winter将技术方案有了一个比较系统的划分：

• 缓存： 客户端的强缓存策略
• 降低请求成本：
  1. HTTP DNS: 由客户端控制，隔一段时间主动请求DNS获取域名IP，不走系统的DNS
  2. TCP/TLS连接复用：由服务端升级到HTTP2，并尽量合并域名
• 减少请求数：
  1. JS，CSS打包到HTML
  2. JS控制图片异步加载、懒加载
  3. 小图用data-url
• 减少传输体积：
  1. 尽量使用svg/gradient等代替图片
  2. 根据机型和网络状况控制图片清晰度
  3. 对低清晰图片使用锐化来提升用户体验
  4. 设计上避免大型背景图

  以上列出的仅仅是部分技术方案事例，但是可见，需要产品、设计、服务端等多方面的协作去完成。因此，性能优化一定是团队事件，而不是有着局限性的个人模块。

4. 执行

  有了方案就要贯彻执行。一个良好的团队，一定有高强度执行力。当然，执行一样不简单。方案靠技术，那执行则靠工程了。
  三个阶段工程水平从低到高如下，而结合多数公司现状，由于自动化成本过高，因此建议制度化+自动化搭配执行，以求高效率高质量。

1. 纯管理
2. 制度化
3. 自动化

5. 结果评估和监控

  一个阶段的工程实施，必定要有阶段性的工程结果和总结。而结果总结并不意味着是最终答卷。此过程是一个长期过程，而分割为多个短期节点或者里程碑。这就要求不光要有结果，还要不断优化，不断更新。那就意味着，我们还需要做好线上监控。线上监控要做好，两个数据不可少：

1. 数据采集
2. 数据展现

总而言之

  总而言之，性能的优化，应该基于公司实际业务和实际的用户需求体验而做的一种工程实施，而不是单纯的技术游戏。

参考：《极客时间》之《重学前端》