重学前端-性能优化的记录
脱离profile谈性能是不可取的，性能不是一个纯粹的技术游戏，应该根据具体业务场景来谈性能优化，性能优化要着眼于工程，前端，后端都要考虑。
性能体系优化实践过程分以下过程：
- 现状评估和建立指标；
要想做好性能优化，首先要进行现状评估听建立优化指标。
作为一个工程师，指标又要考虑两个因素。一方面，对用户来说，什么样的性能指标能更好地评估它的体验？另一方面，对公司来说，什么样的指标会影响业务价值呢？
性能问题可以分成很多方面，最重要的几个点是：页面加载性能；动画与操作性能；内存、电量消耗。注意，这里我们仅仅是对“性能”两个字的分析和解读。
在对大量的用户数据分析后，我们发现，其实这三部分中，“页面加载性能”跟用户的流失率有非常强的关联性，而用户流失率，正是公司业务非常看重的指标。
所以，接下来主要以页面加载性能为例进行讲解，页面加载性能一个很好的评估指标是秒开率。秒开率指的是即一秒之内打开的用户占用户总量的百分比。
- 技术方案；
接下来我们要制定具体的实施方案了。
首先我们要简单分析一下，从输入 URL 后按下回车，到底发生了什么。我们在浏览器的原理课程中，已经讲解了浏览器大致的工作过程，但是，我们必须理解几件事：从域名到 IP 地址，需要用 DNS 协议查询；HTTP 协议是用 TCP 传输的，所以会有 TCP 建立连接过程；如果使用 HTTPS，还有有 HTTPS 交换证书；每个网页还有图片等请求。从这个分析和实际试验的结果看，网页的加载时间，不但跟体积有关系，还跟请求数有很大关系，因此，我们最终设计的技术方案大约可以这样划分：
这里仅仅列出了性能优化的一部分技术方案，是我认为比较重要的部分，可以看到，这里涉及的并不仅仅是前端技术，有服务端、客户端、设计师团队，所以要想做好性能优化，绝对不能把自己限制在局部的视角，必须是整个业务一起考虑，才能有良好的收效。
- 执行；
接下来， 根据技术方案，制定具体的执行过程。
根据公司的实际情况，工程实施可能有不同的程度，我把工程水平从低到高分成三个阶段：纯管理；制度化；自动化。
- 纯行政管理，是由经理用纯粹的管理手段来执行方案，比如说，作为前端团队的 Leader，我可以组织会议，要求整个团队使用我们前面谈的技术方案。但是纯行政管理有一些问题，一方面，需要的行政资源不一定有，比如我没法强制让后端团队配合我，另一方面，纯粹的管理方式，团队本身的体验并不好，也不利于团队成长，最重要的是，纯粹管理方式容易造成执行不到位。这样的执行方式多数出现在非技术岗位。
- 制度化执行方式是用规则代替人的命令，指定责任人，通过培训、checklist、定期 review 等具体措施来保证实施。制度化执行可以极大地减轻管理工作量，一般现代互联网公司都会采用类似的方式。但是制度化执行方式还有很大成分是依靠人的主动性的，对程序员来说，还有更好的方式：自动化。
- 自动化的方式是在一些重要的操作路径上设置规则，针对我们的性能优化，有两个点适合做这件事：一个是把开发好的页面发布上线，另一个是开发好的页面 URL 投放到首页等处的链接。在我之前的工作中，我们跟测试团队配合，开发了一套页面性能打分系统，它会自动扫面页面上的可优化点，并且跟发布平台和投放平台合作，把它加入日常机制中。现在多数公司都会采用制度化和自动化结合的执行方案。
- 结果评估和监控。
执行完了之后，还要有一定的结果总结，才是一个完整的工程实施，而且，凡是工程实施，肯定要有一定长效机制，不能优化完了退化，这些都要求有线上监控机制。
要想做线上监控，分两个部分：数据采集；数据展现。
有了监控，再配合一定制度，就可以保障整个团队产出的性能了，要注意，性能不是一个静态的事情，指标需要不断优化，技术方案还需要不断随着技术发展迭代，制度、自动化工具也需要不断改进，最终的监控平台产品也不能不做新需求，所以性能应该成为一个团队的日常工作的一部分，持续进行。