当你接手一个前端性能优化时,你该如何规划

前言

在两年前第一次接到性能优化任务时,我是一脸懵逼的,虽然脑海里也或多或少能扒拉出一些手段,但总感觉无法连成一条线,不知从何入手,最终的效果当然也不尽如人意;一年后又接手一个新的项目,领导让我重操旧业,重新做性能优化,优化的过程一开始同样并不顺利,好在后面坚持了下来,最终终于有了些阶段性的成果,时至今日感觉自己才刚摸找点门道,所以想由此记录一下,今天我们不谈术的东西,就聊聊道的方面,到底当我们接手一个性能优化专项后,我们该如何规划。

概述

我个人总结性能优化需要从以下六个步骤入手,从上到下循序渐进,这才是一个完整的性能优化周期,下面分别介绍一下这几个方面。

当你接手一个前端性能优化时,你该如何规划

确立指标

在做性能优化前,首要的事情就是要确立指标,指标既可以衡量当前产品性能的现状,也是日后论证你性能优化动作好坏的佐证,所以指标很关键,如果你去搜索,可以发现能够用来衡量页面性能的指标很多,比如常见的 FCP、FMP、TTI、FLT,除了业界常用的指标外,一些公司还有自己内部自定义的指标,还有的会以页面录屏时间作为口径,这里我建议根据自己业务情况,尽可能选择能够真实体现用户体感的性能指标,比如 TTI(可交互时间),这样能更真实体现我们性能优化的业务价值,也不至于陷入技术人的自嗨。
当你接手一个前端性能优化时,你该如何规划

性能监控

当你确定好指标之后,下一步就是要做性能监控了,性能监控是为了能够拿到线上真实用户的数据,实验室的数据毕竟是小规模的数据,真实用户的场景要复杂的多。

上报方式: 上报方式多种多样,我这里用的是埋点上报的方式
上报时机: 根据你选择的指标确定上报时机,比如如果是 TTI,那你需要在页面主要内容渲染完成时进行上报
数据呈现: 上报的数据需要以数据报表或大盘的形式能够直观的展现出来,另外建议如果是长周期的性能优化,要注意数据留存时间,有些监控产品只会保留近1个月的数据

当你接手一个前端性能优化时,你该如何规划

确立基线&目标

当上面两步完成后,你就可以获取到当前业务产品的性能水位了,基线就是当前水位,比如当前整体项目的性能 TTI 在 3s ~ 4s,那基线就是 3s ~ 4s,根据基线你就可以知道目前性能的好坏,以及后续的目标,一开始可以先设立一个小目标,这样不至于让自己还没做就产生想放弃的念头,性能优化就是一个不断自我优化的过程,没有谁能一上来就达到终态。

性能优化

下面才真正到了平时常说的性能优化环节,只有上面三个步骤你都做到位了,你做性能优化时才知道具体该优化什么,怎么衡量优化的效果,优化到什么程度算达标。

当你接手一个前端性能优化时,你该如何规划
下面我将从七个方面来说如何进行性能优化:

页面各阶段耗时上报

你可能会说上面不是说过性能上报,怎么这里又提,其实当你真正做了之后,你就会发现那些大的指标只能作为性能好坏的尺子,但是却不能为你做性能分析提供更多的帮助,你无法从 TTI 3.6s 知道到底这 3.6s 是由哪些部分组成的,是哪个阶段的耗时拖累了整个页面,所以我们需要把指标拆解,拆成更细的维度进行上报。

这里我列举了页面三个阶段的耗时上报,你也可以根据自己的业务情况拆解更细的颗粒度。

当你接手一个前端性能优化时,你该如何规划

主文档耗时优化

主文档耗时就是指 HTML 获取的时间,这块的优化措施我了解的不多,能够想到的就是将 HTML 分发到 CDN 节点上,另外就是尽可能精简 HTML 的尺寸。

当你接手一个前端性能优化时,你该如何规划

资源加载耗时优化

资源耗时其实是页面整体耗时中占比比较大的一环,优化措施基本上都比较固定,所以我就不过多介绍了,就一句话:能不请求就不请求,实在要请求尽可能并行请求
当你接手一个前端性能优化时,你该如何规划

接口耗时优化

除了资源耗时外,另一个占比较大的就是接口耗时优化了,这里主要介绍一下接口预请求,这是我在实战经验中体感最有效的一种方式:
接口预请求: 接口耗时难在有时还 RT 并不高,但是接口整体耗时却很长,这就是因为接口网络传输耗时较长导致的,你没办法控制用户的网络环境,所以比较有效的方法就是预加载,其实整个页面加载是一个串行的链路:HTML 加载 -> 资源加载 -> 组件初始化 -> 接口请求 -> 组件更新,接口请求在比较靠后的位置,其实我们完全可以利用请求并行的机制,让接口在第一阶段(HTML加载)完成后就立即发起请求,这样等到业务逻辑需要的时候,接口数据已经拿到了。

其实缓存也是一种不错的优化手段,如果你的站点属于多页应用,那你可以在上一个链路提前请求下一个页面的接口数据进行缓存

当你接手一个前端性能优化时,你该如何规划

图片耗时优化

其实这里应该是多媒体资源耗时优化,但是想了一下,业务中大部分场景都是图片资源的优化,其它资源基本上没有涉及,所以这里还是重点说一下图片资源的优化吧,其实图片资源的优化类似于”JS资源加载耗时优化“,总的来说就是减少体积,当然如果实在体积难以减小还可以优化加载时机,这里主要介绍一下前两个优化措施:
图片预加载: 和接口预加载类似,图片也可以预加载,当然这里的区别在于图片预加载会抢夺一部分其它资源的带宽,所以如果用户网络环境不是那么好,还是建议把有限的带宽给 JS 等更重要的资源上
大图切分: 如果你的业务里面经常出现一整张长图,其实可以考虑把一张大图切分成多份,这样可以尽可能的去并行加载。

当你接手一个前端性能优化时,你该如何规划

业务逻辑执行耗时优化

业务逻辑执行耗时优化就比较千人千面了,毕竟每个团队的业务逻辑都不一样,但是还是有些公共的方法,比如能渲染一次的组件,肯定比渲染三次性能好好,还有就是一些复杂逻辑的优化,这个不好说,需要打点去分析,因为我们曾经发现同样的代码在 Android 里面执行耗时就要比 iOS 长很多。

当你接手一个前端性能优化时,你该如何规划

加载体验优化

除了直观指标的提升外,用户的体感也很重要,试想一下,如果你的页面在网络环境不好的情况下,先是一段白屏, 然后终于有内容出来了,但是你刚想点击,一个内容区域突然蹦出把上面的内容顶到了下面,你会作何感想,所以我们不仅要数值上的快,也要用户体验上的快
页面loading: 在页面内容出来之前占位用的,避免用户一直看一个白屏,不知道发生了什么
骨架图: 降低 CLS(累积布局偏移)的,防止页面内容一跳一跳的
当你接手一个前端性能优化时,你该如何规划

性能预警

上面这些措施如果你都做到了,那恭喜你,性能优化的 80% 你都已经完成了,那剩下的 20% 是什么呢,就是防止劣化。性能预警就是防止劣化的其中一环,如果没有性能预警,那你要不就得每天花时间去大盘上看数据的涨落,要不就是某一天你发现性能数据突然劣化,前者费时费力,后者后知后觉。
具体的预警手段多种多样,主要是根据上面设定的指标来,比如 TTI < 2s, 或是 TTI 日环比 > 40%,具体的报警规则可以根据自己的实际情况来定。

另外如果你报警信息能够具体到某个页面,这样最好,越细致越能提高排查问题的效率

日常值班

除了性能预警外,日常值班机制也是防止劣化的重要一环,你要把性能优化的经验沉淀成手册,给全组同学分享,让大家日常都参与进来,性能优化是一个长期的过程,仅凭几个人去跟进只会疲于奔命,落入你优化后,其他人因为开发不注意导致劣化,然后再优化的循环中,所以让全组同学参与到日常值班中,也变相提高了大家对于性能优化的意识,平时开发过程中就能够有意识的去规避一些性能问题。

总结

做了这几年的性能优化,我的最大感悟就是性能优化有几个特点:

  • 性能优化是一个系统性的工程: 不仅是那些具体的优化手段,还包括确立指标,性能监控、确立基线&目标、性能预警、日常值班等,这些步骤少一个,都可能会变成一个半吊子工程,就算优化好,后面也很容易反弹
  • 性能优化是一个长期工程: 可能不同于其它技术项目,达到既定里程碑就完事了,性能优化只有阶段性的结果,但是只要你的项目一直在线上运行,一直在迭代,性能优化就不会结束。
  • 性能优化不可操之过急: 没做过的人总想在短期内能快速把性能提升上来,但是性能优化没有一个万能银弹,一招搞定的措施,大部分都是很细碎的小点,这些细碎的优化措施随着量变而产生质变,更何况也不是所有措施都是有效的,这就像做实验一样,你需要经过方案设计 -> 本地验证 -> 线上数据观察 -> 方案调整,然后不断重复这一套流程。
    以上就是我个人做性能优化的一些道上面的思考和经验,希望能帮到正在做或后面要做性能优化的你,最后附上整个脑图。

当你接手一个前端性能优化时,你该如何规划

原文链接:https://juejin.cn/post/7351649413402918964 作者:渴望做梦

(0)
上一篇 2024年3月30日 下午4:17
下一篇 2024年3月30日 下午4:23

相关推荐

发表评论

登录后才能评论