一次失败的性能优化
date
Mar 1, 2023
slug
review-site-perf-optimization
status
Published
tags
思考
性能优化
type
Post
lang
summary
去年 5 月份的时候，老板催着找点事情做，由于当时我们的应用的性能非常拉，FCP 75 分位能给干到 3 秒，LCP 5 秒左右，有些重点页面加载速度更慢。同时用户对于页面加载速度的反馈也比较多，所以当时就把这个事情接下来了。从标题可以知道，这件事并没有做好，当时做到一半之后就不了了之了，做的事情也换成了和自身业务挂钩的东西。
后来过了几个月有大老板又关注到我们应用的性能问题了，当时负责主应用（微前端架构中的主应用）的组内大佬又重新把性能优化的事情搞起来了，做了两个多月就有不错的收益，从大佬的分享中我也从中学到不少东西。
其实之前有过反思自己为什么没有把事情做好，但是一直没有坐下来细细写一篇文章进行仔细复盘，但这是非常有意义且必要的，所以还是抽时间思考整理一下。
为什么没做好？
why why why？为啥没做好呢，差不多过去大半年了，过了这么久，让现在的我瞎分析一下吧。
目标不清晰
目标不清晰不是指的没有定目标。从现在的我来看当时定的几个目标，可以理解为当时定的不是目标，而是一些具体行动。
例如：“梳理可落地性能优化点，完成整体规划文档”、“性能指标明确性能指标，完成性能数据收集”、“SSR 落地”、“降低 FCP 到 x 秒” 等等（更离谱的目标我都不好意思说😅）。对于当时的我来说，我理解这些东西就是性能优化需要的目标。
但其实并不是这样的，这些目标只是看起来像目标的关键动作，而不是做性能优化事情的真正目标。当然，“降低 x 性能指标到 y 秒” 的指标也可以算做一个细分的指标。但这些都不应该是真正的指标。
从我现在的角度来看，真正的指标应该是 “提升用户满意度 x%”，而数据上的指标如 “降低 FCP、LCP” 则更多是细分指标。
而对于 “性能指标明确性能指标，完成性能数据收集”、“SSR 落地” 这种，则根本不能算的上是一个合格的目标。
虽然 “降低 x 性能指标到 y 秒” 这种指标确实应该是我们研发应该关注的重点，但并不是全部。因为做的事情是优化页面性能，最终耗费的资源是需要带来业务上的收益的，所以用户侧的反馈对于用户来说才是更加重要的指标。
没有找对 “正确的动作”
当时看了很多关于性能优化的文章，都列举了一些对于性能的优化方案。例如：减小包大小、减少首屏依赖、SSR、SSG、解决重复依赖等等。
当时的应用其实是有非常多的点是可以被优化的，“首屏包过大”、“重复依赖过多”、“无 SSR SSG”、“首屏依赖 API 过多” 等等，基本上常见的优化点我们都可以去做。
但是对于不同的选择，ROI 是不同的。在没有进行足够的前期调研之前，随意选择优化方案可能会浪费时间和资源，而且优化的效果也不会很明显。
人就这么几个，怎么选择做哪些事情其实也是非常关键的。例如，我想优化 FCP 时间，但其实首屏同时被 “资源加载 & 解析 + 首屏 API 请求” 阻塞住的，且 API 阻塞的时间更长。那么这个时候，如果拍脑袋去做如 “首屏包大小优化“ 那么其实是完全无收益的。
如上图，可以看出来，这样优化后的 FCP 时间是完全不会变化的。
当然我在做性能优化的时候并没有犯这个错误，当时也做了详细的性能链路分析图，仔细分析了应用在各阶段中的时间消耗图。可惜的是，当时还是没有找到最有效、ROI 最高、最快能出效果的优化方案。
注：现在这么说当然是因为组内后来的大佬优化做的很好，自己也是学到非常多。
缺少对竞品分析和学习
在做性能优化时，对于竞品的研究也是非常重要的一环。
我虽然做了调研，但是做的并不够好。当时做的调研是别的平台用了什么方案，速度有多快，各指标的时间分别是多少，同时对将我们的应用和其他竞品平台进行对比，看看差距多少。
后续老板带我做调研的时候给我好好上了一课，什么才是好的调研（当时已经没有做了，只是有那么个场景一起分析了一下）。
简单的概括为一个字：“学”。
学习别人为什么这么快，仔细分析，不放过任何一个小点，看看别人到底用了什么方案能让应用加载速度比我们快这么多。
这么简单的道理为什么当时就没有学会呢。。。其实性能优化这种事情真是非常容易 ”抄袭“ 的一件事，照着优化就好了，没那么难。
不重视用户调研
上面也说了，当进行应用性能优化时，应该将提升用户满意度作为最重要的指标之一。因为应用性能的提升应该是为了提高用户满意度，而用户满意度是应用运营的核心目标之一。因此，在进行性能优化时，需要从用户需求和用户满意度入手，定义真正的目标，而不是一些具体行动。
当时在做优化的时候，其实是需要把用户反馈放在第一位的，通过问卷或其他形式，收集用户对于网站体验的反馈，是非常必要且紧急的。
但是我当时并没有做好这一点，简单提了让运营帮忙发了一下问卷后好像就不了了之了。对于当时的我来说，只要能提升性能指标，自己就认为可以了。
当然当时 leader 也反复和我强调，如果没有业务指标来验证你的结果，其实做的事情是没有那么大的说服力的，也就是就算做的很好，只要没有用户反馈上的指标，那么就不会有非常好的绩效。
好的部分
在之前的复盘中，我总结了一些未成功的经验教训。但其实也有一些好的部分，顺便整理复盘下。
有性能链路分析
对应用的整体性能链路进行分析，简化图（省了无数的东西，看个热闹）大概长这样：
当对应用的性能链路进行完善的分析后，才能够知道，我们的应用到底慢在了哪里。哪里才是最值得我们投入时间去进行优化的。
而不是拍脑袋觉得某个行动一定会有效果，这是万万不可的。
可惜的是我只对自己的应用做了非常详细的分析，没有分析分析别人的，然后抄抄作业，当时咋就没想到呢 😭。
重视数据收集
性能优化最重要的数据上的收集，在做性能优化前需要把所有的指标都先打上点。方便后续在上各种优化功能点的时候能有对应的数据。
这个数据打点需要越细越好，最好在完成性能链路分析之后把所有需要优化的地方都加上打点。
例如上图标蓝处进行打点，当我们在所有节点上都加上埋点后，我们的每一步动作所优化的时间都是可以被明确的，这样才可以去保证我们的行动是否有效。
收获性能优化的经验
诚然在业务上并没有做出太大成绩，但是不可否认的是学习到了如果做性能优化这件事。如果再让我来做一次的话，必然会比上一次做的好（应该不会差把咱就是说…）。
总结
多反思，多复盘。