前端晋升答辩-性能优化篇范式
本文力争为你参加晋升答辩时，提供一个论述性能优化相关工作的范式。简单点儿来说，就是按照这个范式文来准备、阐述，就可以博得晋升评委的认可与喜爱。
痴迷写页面UI的前端千篇一律，懂得量化收益的前端万里挑一。
现在已经不是刀耕火种的前端原始时代了，能够高保真实现页面UI是每一个前端的基本技能，“没有功劳还有苦劳”这句话也不再适用于前端晋升了。你辛苦的工作可能会看在直属leader的眼里，知道你为了业务天天熬夜加班，会让你年终绩效更好一些，但是在晋升答辩中，尤其是高职级同学的晋升，基本都是跨部门、或通道评委评审的，他们是不会认为这些重复性劳动、像流水线一样的工作有什么重要价值。
如何让他们在短短时间内认识到你的工作价值呢，这是你在晋升之前要思考的问题！
为啥要选性能优化这一点来做范式呢，因为这个听着高大上，每个前端同学晋升时都想提、都会提，但是经常看到很多同学答辩时因为这个反而被刷了下来。很多同学想不明白的是，明明我这个工作已经做了，页面效果也很OK，leader和用户都有正向反馈了，但为啥还在这里栽跟头呢？
核心点 - 如何量化自己的工作，量化收益，让工作看得见，看的明白。
以下会以五个方面来完整的描述你在性能优化方面所做的辛苦付出，体现出你的成果价值与思考。
一、需求来源
首先要想明白，有些需求是被安排的，有些需求是需要主动出击的，这牵扯到一个主观能动性和个人推动协调能力。
就性能优化而言，可能是用户反馈体验卡顿，产品或老板给安排过来。也可以是你细致观察监控数据，认识到性能有提升空间，然后将问题和解决方案摆到老板面前。
在晋升答辩时，一定要把你主动发现问题，提出解决方案，推动PM确定为需求，排期、研发上线这个过程阐述出来。 谁推动，谁就是这个需求的最大受益者。
二、指标数据与标准锚定
kotlin
复制代码
if (没有历史指标数据) { return false; // 后面的工作将无任何意义！ }
如果你在做性能优化之前，没有历史指标数据，那么请你立刻停止性能优化工作。调转头来，现将现有相关性能指标数据收集起来。
当一个实验组没有对照组，这个实验也没有了存在的意义。如果你的性能优化工作没有明确的可参考数据，可确定的标准，请你不要做！做了也没有任何收益！因为没有办法体现出来！
选定业务场景
在做页面性能优化时，不要把目光窄窄的聚焦于首页加载性能优化，更多的可以是根据实际业务场景，选择一个核心业务页面，影响用户的关键性节点，比如在可视化系统中看板页面（展示各种数据图表）、电商系统中的商品搜索、支付环节、信息推送中的feed流等等。
有业务场景，做优化才有意义。
历史指标数据收集：
选择收集历史指标数据是为了与进行性能优化后的的数据进行对比的，所以我们一定要选择一种权威性的方式来收集这些数据。
-
首推公司内部性能监控平台
公司内部统一的，所有数据指标的定义、收集、口径都是统一的，当一项数据耗时3s，降低到2s，所有公司内部的人都是必需得承认，这个优化是有效的。
-
自行从Lighthouse和Performance检测到的性能数据
当我们从Lighthouse或者Performance中去收集数据时，可能会因为本身电脑原因，或是样本数据量比较小，不能形成有效的数据支撑。
-
第三方性能测试网站如Pingdom、SpeedTracker等。
因为“墙”的原因，一些国外的网站，我们在进行测试时，数据不准确，而且自行测试时，样本量数据小。
某些业务数据因敏感性，不能传递到公司外部，这些都是要进行考量的。
所以说，有条件的一定要使用性能监控平台，次之选择Lighthouse/Performance，再次之选择一些第三方性能测试网站。
性能优化指标：
性能优化指标分为两种：一种是前端常见核心性能指标，一种是业务自定义指标
前端常见核心性能指标：
| 指标名称 | 全称 | 描述 |
|---|---|---|
| FP | First Paint | 浏览器第一次绘制时间，第一个像素时间 |
| TTI | Time To Interactive | 页面渲染完毕，可以响应用户输入的时间 |
| FID | First Input Delay | 用户与页面输入框等控件第一次可交互的时间 |
| LCP | Largest Contentful Paint | 最大内容绘制时间 |
| FMP | First Meaningful Paint | 首次有意义的绘制，页面主要内容出现在屏幕的时间 |
| FCP | First Contentful Paint | 浏览器第一次屏幕绘制内容时间 |
| CLS | Cumulative Layout Shift | 累计布局版式位移，页面抖动，屏闪 |
自定义指标：根据实际业务需要，自定上报统计的关键业务节点时间，比如一个图表从数据请求到绘制绘制完成的时间。
标准锚定：
在现有历史性能指标数据的基础上，遵循行业内优秀性能数据表现，或从实际业务出发，确定什么样的耗时是符合标准的，什么是优秀的。
这个标准必需要提前确定下来，达成一致。这样在做性能优化时就有了参考点，知道往哪个目标方向走是正确的。
三、收益预期
性能优化是一件非常讲究ROI（投资回报率）的事情，在这里你一定要向你的老板画饼，表达出做这样工作耗时短，收益高，在用户体验这块儿有很大的飞跃。
没有ROI的，可做可不做的事情，就一定不要做。
你不能说给我2个月的时间，我可以把现在页面加载耗时10s降低到1s，先不说你1s能不能做到，就单2个月这个时间老板基本就不会同意了。
在这里一定要产出一个明确的目标数值，比如我们要把这个指标从10s降到5s，性能提升一倍。这个也是为了将来做收益对比的。
这里还有一个套路就是，给出一个保守的目标值，然后做成之后会突破这个值，对于老板来说也是个惊喜。
温馨提示：吹牛有风险，装B需谨慎！自己心里一定要有谱，把性能耗时从2s降低到1s，远远要比从10s降低到5s困难的多得多。
四、性能优化策略
性能优化的策略有很多种，要根据自己的实际业务需求对症下药。常规的一些如懒加载、分包策略、滚动加载、上Http2、Gzip压缩等等，这里不是文章的重点，不做过多描述。
在答辩时，这块儿据实而说即可。
五、量化收益
重点来了！！！在进行性能优化后，一定要再次进行指标数据观测、统计，做好收尾工作。没有这一步，前面的工作也是白做了。
辛苦付出，一顿操作，究竟数据是不是达到了预期呢？
如果有性能监控平台，这事儿就特别好办，查看下对应的日、周、月维度的数据，观察相应的耗时曲线是否降低。
在答辩时，一定要提供一些图表，至少是表格的数据，将前后收集的关键性指标数据进行对比，凸显所做出的的效果，让评委直观的看到数据的变化，一眼就感受到你所做的性能优化是非常好的。
如果某个重量级领导也肯定了你的该项成绩，记得一定要在答辩时以或直白或委婉的形式想评委们透露出来，哪加分，不要不要的~
综述
本文的重点在于为你提供一个晋升答辩时，向评委论述性能优化的范式，不是具体的性能优化策略实施。
通过五个环节的梳理，展示，评委会在短时间内非常系统、非常具象的看到你在性能优化方面做出的成果与价值，也会看到你的技术视野与思考。
如果你是打算在今年年底晋升答辩，现在已经可以着手做了，统计历史指标数据，确定优化目标、预期收益，性能优化策略研发上线，量化收益结果。
同时非常欢迎大家评论、分享自己的晋升经历和经验，为前端小伙伴谋福利。
量化自己的工作，量化收益，让工作看得见，看的明白。
作者：胡哥有话说
链接：https://juejin.cn/post/7126986286367244324
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。+