一次失败的性能优化
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 也反复和我强调,如果没有业务指标来验证你的结果,其实做的事情是没有那么大的说服力的,也就是就算做的很好,只要没有用户反馈上的指标,那么就不会有非常好的绩效。
好的部分
在之前的复盘中,我总结了一些未成功的经验教训。但其实也有一些好的部分,顺便整理复盘下。
有性能链路分析
对应用的整体性能链路进行分析,简化图(省了无数的东西,看个热闹)大概长这样:

当对应用的性能链路进行完善的分析后,才能够知道,我们的应用到底慢在了哪里。哪里才是最值得我们投入时间去进行优化的。
而不是拍脑袋觉得某个行动一定会有效果,这是万万不可的。
可惜的是我只对自己的应用做了非常详细的分析,没有分析分析别人的,然后抄抄作业,当时咋就没想到呢 😭。
重视数据收集
性能优化最重要的数据上的收集,在做性能优化前需要把所有的指标都先打上点。方便后续在上各种优化功能点的时候能有对应的数据。
这个数据打点需要越细越好,最好在完成性能链路分析之后把所有需要优化的地方都加上打点。

例如上图标蓝处进行打点,当我们在所有节点上都加上埋点后,我们的每一步动作所优化的时间都是可以被明确的,这样才可以去保证我们的行动是否有效。
收获性能优化的经验
诚然在业务上并没有做出太大成绩,但是不可否认的是学习到了如果做性能优化这件事。如果再让我来做一次的话,必然会比上一次做的好(应该不会差把咱就是说…)。
总结
多反思,多复盘。