本文为极客时间学习笔记+自己的一些想法。
当我们在说性能的时候，我们在说什么？
性能，在前端扮演着很重要的角色。首屏加载、页面卡顿，这些都是被用户日日吐槽的事情。那我们该从哪儿入手呢？
性能分析：如何搭建性能体系
性能分析，即performance analysis也称为profiling。是以收集程序运行时信息为手段研究程序行为的分析方法。目标在于决定哪些程序应该被优化，从而提高程序的效率。
有价值的性能优化，必定是从端到端的业务场景建立体系来考虑的。性能体系的建立，可以分为以下：
- 现状评估和建立指标；
- 技术方案；
- 执行；
- 结果评估和监控。
1. 现状评估和建立指标：最关键的一步。
两个出发点：在性能方面，用户爽公司才会爽。但公司方面还会考虑成本问题。
- 对用户来说，什么样的性能指标能更好地评估它的体验？
- 页面加载
- 流畅的交互体验
- 体积不要太大、内存和电量损耗
- 对公司来说，什么样的指标会影响业务价值呢？
- 页面加载性能：首屏加载、页面卡顿等，与用户流失率强相关。
用什么来衡量页面加载性能？秒开率：即一秒之内打开的用户占用户总量的百分比。
2. 输出技术方案：秒开率，及如何实现
从“用户平均加载时间”到“秒开率”这个过程的思考：
- 平均，不适合作为指标。联想倒U型曲线，大部分都会分布在顶点临界值，但是两侧数据会大大拉低数据。（专业词todo）
- 秒开，是通过脑科学进行的一种输出。用户对于1s内打开就无感知？（理论支撑todo）
用户打开一个页面需要的过程：
- 从域名到 IP 地址，需要用 DNS 协议查询；
- HTTP 协议是用 TCP 传输的，所以会有 TCP 建立连接过程；
- 如果使用 HTTPS，还有有 HTTPS 交换证书；
- 每个网页还有图片等请求。
创新，就是把整条链路拆解成一个一个小步骤，然后在每个小步骤里找优化点。
思考及todo：
首先，这里要有一个过程图，过程图上拆解可优化的行为；
第二，这个图是结果图，是从过程图上拆解后的分类，这个图只能让用户从这个分类里继续细分，而无法回到过程上去创新。
第三，从过程到功能，从功能到分工，这样就可以站在一个整体的角度上去看这个事情。要用好周边资源，或者说发动周边资源。
3. 执行：工程实施
按照工程水平可分为三个阶段：纯管理-制度化-自动化。（自己在哪个阶段呢？）
纯管理：领导通过“要求”来让大家一起执行。（让所有的跨团队来支持你，有点困难；不过我们接触的纯管理好像也比较少，管理一定要搭上具体的手段才可以落地，要不太虚空了。）
制度化：设置规则，指定责任人，通过培训、checklist、定期review等手段，来实现。（一般都采用的这种，另外checklist、review应该是一种日常行为，这种行为会孵化出一些自动化工具。）
自动化：在重要操作路径上设置规则。（其实，这个不算是自动化吧，顶多是有一些自动化工具加持，部署现在稍微好点，但是前端的自动化之路，还是挺费劲，比如从视觉稿到代码初稿，二次开发，代码review，视觉review，业务逻辑实现；不过脚手架的能力现在确实越来越强了，另外还要考虑安全与自动化之间的关系，自动化就会出现边界。不过，我们还是有很多事情要做的。）
回到性能分析这块，借助性能指标 Performance API，可以输出一个工具，对页面进行打分。目前站内也是有此类工具。
4. 结果评估和监控
借助监控工具完成数据采集与数据分析。
不过有时候这些监控工具会落到运维头上，他们开发工具，满足前端诉求。这时候也有可能需要前端一起开发。而数据分析这块，就更是一个比较困难的问题了。还好，性能分析这块，有业内的标准，已经比较成熟。借助性能分析模型，就可以一步步深入分析自己的页面问题了。
另外，除了技术问题，从整个产品和交互设计上，也会有阻塞性能的因素，而这个就要更深入了；同时，后端接口和运维能力都是相关的制约因素。如何找到人然后找到方案并落地方案，有时候也会涉及一个团队合作的问题。
技术是单纯的，而人是复杂的。
总结
这实在是一篇太面上的内容了。不过给了一个大概的思路，而回到性能上，抠细节没毛病，但要抠对。
我会继续持续更新这篇文章，把自己的一些想法再陆续更新。
初稿笔记 2023.2.23
