序
开题之前，思考以下三个性能比较：
for循环和while循环哪个更快？
Math.floor是否比|0更好?
多个if-else是否要用switch-case替代?
前端发展至此，前端性能随之变成了一个很有意思的话题。从入门级别的初级工程师，到高级别的专家，都离不开性能问题。那么前端性能该如何理解呢？
总论
前端时间学习前淘宝前端总负责人winter的课程，受益颇深。前面三个性能比较的例子，在社区或者论坛中大家对此的讨论从未断过，也乐此不疲。但是，它们出了让你写代码的时候纠结之外，毫无意义。
比如，在写业务的时候，某一个功能模块有数据操作，千方百计的将某个循环操作优化了，可能执行效率提高了一倍。可是在整体来看，页面打开速度一样，用户也没有任何良好反馈，甚至测试都毫无察觉。因此，性能优化不能局限于局部代码。用大佬winter的话来讲，就是一切没有profiling的性能都是耍流氓。凡是真正有价值的性能优化，必定是从端到端的业务场景建立体系来考虑的。
流程分析
那么我们从何入手，又该怎样考虑和执行呢？总结如下：
- 现状评估和建立指标
- 技术方案
- 执行
- 结果评估和监控
1. 现状评估
此处，要解决的问题有两个：
- 从用户体验来讲，什么样的性能指标能更好的评估产品的体验？
- 对公司来说，什么样的指标会影响到公司业务价值？
性能问题大致分为三个层次：
- 页面加载；
- 动画与操作；
- 内存，电耗；
2. 建立指标
从这三个方面来看，如果一个页面在经历了几秒的白屏才打开，那注定用户流失率会极其高。而用户流失率是公司所注重的，因此页面加载则是重中之重。因此，需要大量评测页面加载时常对用户的影响。大量数据表示，加载时间在1s以内，差别都不大。因此首要就是正常网络状况下，加载时长要优化至1s以内。但是会碰到一个新的问题，就是少数极端网络用户（如2g网络）加载时间会极长，在统计后，会极大的拉低平均加载时长，从而影响整体的指标。因此，指标不能反应大多数的用户体验。因此，他们团队提出——秒开率：一秒之内能打开的用户占总用户的比重。
3. 技术方案
有了目标，便需要以技术手段去解决问题了。在课程中，winter将技术方案有了一个比较系统的划分：
- 缓存： 客户端的强缓存策略
- 降低请求成本：
- HTTP DNS: 由客户端控制，隔一段时间主动请求DNS获取域名IP，不走系统的DNS
- TCP/TLS连接复用：由服务端升级到HTTP2，并尽量合并域名
- 减少请求数：
- JS，CSS打包到HTML
- JS控制图片异步加载、懒加载
- 小图用data-url
- 减少传输体积：
- 尽量使用svg/gradient等代替图片
- 根据机型和网络状况控制图片清晰度
- 对低清晰图片使用锐化来提升用户体验
- 设计上避免大型背景图
以上列出的仅仅是部分技术方案事例，但是可见，需要产品、设计、服务端等多方面的协作去完成。因此，性能优化一定是团队事件，而不是有着局限性的个人模块。
4. 执行
有了方案就要贯彻执行。一个良好的团队，一定有高强度执行力。当然，执行一样不简单。方案靠技术，那执行则靠工程了。
三个阶段工程水平从低到高如下，而结合多数公司现状，由于自动化成本过高，因此建议制度化+自动化搭配执行，以求高效率高质量。
- 纯管理
- 制度化
- 自动化
5. 结果评估和监控
一个阶段的工程实施，必定要有阶段性的工程结果和总结。而结果总结并不意味着是最终答卷。此过程是一个长期过程，而分割为多个短期节点或者里程碑。这就要求不光要有结果，还要不断优化，不断更新。那就意味着，我们还需要做好线上监控。线上监控要做好，两个数据不可少：
- 数据采集
- 数据展现
总而言之
总而言之，性能的优化，应该基于公司实际业务和实际的用户需求体验而做的一种工程实施，而不是单纯的技术游戏。
