前言

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

概述

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

确立指标

在做性能优化前，首要的事情就是要确立指标，指标既可以衡量当前产品性能的现状，也是日后论证你性能优化动作好坏的佐证，所以指标很关键，如果你去搜索，可以发现能够用来衡量页面性能的指标很多，比如常见的 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%，具体的报警规则可以根据自己的实际情况来定。

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

日常值班

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

总结

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

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