前言
为什么得说“性能优化体系”，而不是方法或者结果导向？
现在太多的人都对【性能优化】这个话题有所了解。 我们来尝试回答一下下面这个问题。
你是如何做性能优化的？
答案1： 优化资源，懒加载、缓存、接口请求优化……（老套筒，没意思）
答案2: 借用浏览器提供的一些工具来衡量一下页面时间，围绕首屏或者首屏秒开做点文章。
答案3: 需要一个具有诊断功能的性能平台来精准的诊断下页面的情况（这问题就大了，涉及到性能平台怎么玩）
答案4: 根据实际情况，搭建性能优化体系，从系统层面来考虑如何作优化的事情。
所以，你是属于哪种答案？
所谓“体系” 是你对现状的一种集成与牺牲
你是否应该先了解公司靠什么业务赚钱，然后看看能不能定制出一些能让业务更赚钱的体系来？ 假如你的体系中制定了指标A，指标A 达到某个数值就可认指标A完成目标。 那由于指标A能让公司业务变得更加赚钱吗？
如果指标A能，那说明指标A是有效的。如果不能，那说明指标A是无效的。举个简单的🌰，行页内电商类APP都在乎秒开这个指标，因为秒开率越高，留住用户的可能性就越高，提升下单转化率效果就越好。 反正，游戏APP（例如王者荣耀、吃鸡），秒开这个指标还重要吗？ 它就没那么重要，因为玩游戏的都愿意等个几分钟，怎么还会在乎你1秒。
所以，先确定你的体系里需要存在哪些指标，再缺制定衡量这些指标的方法。 这个过程就叫集成。
那么，啥叫牺牲？你的体系里其实有很多必要性很强的指标，但是需要先投入成本再经过一段时间才能有产出。换句话说有些事情你不一定来得及做，做了不一定能被老板接受。
所以你有 一个成熟的体系，这个过程还叫做 牺牲。
体系
一图胜千言，先上图。
看完图，你在想想，现在你会如何回答哪个问题：你是如何做性能优化的？
1. 性能优化流程 - 直接行为
开工第一步，先制定指标。
这里有个依据，不能想当然，毕竟最终是要写代码的，所以：
1. 尽量能用代码解释
2. 能被数学解释
3. 能直观衡量用户体验感受 或者 服务优劣
4. 能被老板理解并接受
接着，为你的指标制定标准。 举个两个🌰，
- 秒开指标。 标准是 所有活动页强网秒开率要达 70%，弱网要达30%。
- 降级指标。 标准是 SSR降级率不能高于5%，大促页面降级率不能高于7%。
（我觉得你看懂了）
通过事前预估达成结果后的收益决定做哪些
这里就不多解释了。最重要的还是情商的活儿。 毕竟你也要从老板那那kpi考核的。
根据现状诊断病因
请搞清楚以下几点：
- 病多久了，是否病入膏肓（
这决定你是要重构/优化 系统 Or 业务） - 为什么病这么久 （
你要了解为什么病这么久还能活，能继续活多久） - 客观病因 （
确定是业务差 还是产品营销策略有问题，或者是没钱）
这几点搞清楚了，你再判断是 【快】 、 【稳定】 哪个因素是掣肘你前进的根源。如果两个都是，emm，任重道远。 【快】 是指页面到达快，秒开率高，交互顺畅。 【稳定】 是指异常率维持稳定。
找回你曾经了解过的优化手段
虽然是老套筒了，但还是说一下，点到即止
- 优化资源。 图片、打包后的bundle体积……
- 缓存。 接口缓存、http缓存、资源缓存
- 延迟加载。 也叫懒加载。 重要的内容先加载、渲染。不重要的往后排。
- 预加载/请求。 这点一般需要客户端写协作。 请求接口和获取页面静态资源由客户端提取完成，这样能节省页面请求资源和接口的时间。
- 离线包
- SSR
- ……
保持线上追踪
这里的追踪，如果你指做完了性能优化的一个流程，那追踪大致上是需要人肉工作的。例如实时去盯住一些交易量、下单量、客单价……
但是如果做了监控告警功能，就不需要人工太繁琐的介入了。 这个后面再讲。
逃不过的首屏时间
好吧。不得不承认，你要做性能优化那肯定逃不掉首屏时间 这个词了。 那些拗口的英文单词我就不叙述了，自行搜索即可。
首屏时间=白屏时间+渲染时间。从浏览器输入地址并回车后，到首屏内容渲染完毕（用户能开始进行交互）的时间。
有人问过，为什么会出现白屏的现象？ emm， 毕竟页面是从无到有的过程，那从无到有总得有个过渡时间。 白屏的原因有很多。 客户端启动webview 需要时间，根据经验这个时间很难优化，大约在150-200ms 时间。 如果你需要在渲染内容之前去发请求获取一些资源或者数据，那又会造成不可控的时间问题。 额外的还有离线缓存没做好，首屏内容太多，又或是网络情况不好 ……
所以，白屏时间是必然存在的。重要的是，你选择让它白多久，又让它在什么时候白。
渲染时间就相对简单些。 浏览器渲染进程去渲染首屏DOM。
但首屏时间 意义就比较大了。 我是电商背景，首屏的商品图、价格以及提交下单按钮是无论如何也要保证用户能看见的。 例如大家都经历过双十一抢购，最关键就是加车、下单按钮。
说这么多，如何计算首屏时间呢？ 放心，肯定能计算，不过这个适合在数据采集上报那一步做。这里就先给个首屏时间的标准，仅供参考。
| 类型 | 首屏时间 | 秒开率 | 1.5秒开率 | 2秒开率 |
|---|---|---|---|---|
| SSR | 1000ms | 70% | 90% | 95% |
| 端外 | 1500ms | 35% | 50% | 75% |
| 端内 | 1200ms | 65% | 80% | 90% |
立项
你纠结了那么多，调研了许久，搞了不少事情。 总得最后来个立项吧？我简单分享一下我曾经立项的经历。
立项流程
项目立项就是成立一个项目组，整个项目组来解决问题达到最终目标。立项流程包括：
- 团队成员确定 （
不可能你一个人单干，需要团队合作和跨团队协作） - 技术调研开展 （
分好子目标或者子任务，然后各自去调研） - 项目目标制定 （
根据调研结果，清晰明确的制定各个阶段的目标） - 获取业务方支持 （
用你的诚恳和关怀打动（忽悠）住业务方，比较业务爸爸惹不起） - 需求范围和优先级确定等过程。（
这个关系到具体的测试、产品、UI验收等问题，所以还是要很细致。） - 项目名称就一般用达成目标或者问题描述来起即可。
项目目标制定
有道是根据现状寻找解决方案，最终得到一个结果，而这个结果是希望符合预期的。那么这个过程就是：
根据现状寻找异常 -> 问题根源/痛点 -> 解决方案 -> 可能得到的结果 -> 是否符合预期目标
初始的预期目标是 首屏秒开能达65%，站外秒开率能达20%。 这个目标其实算比较低了些，但……（你懂的，一步步来嘛）。
后来吧，感觉老板可能对这个目标不会太满意。 我说服老板先一步一个脚印（直到偶然有一天听见老板跟另外一个人吐槽 我能力不太行）。 于是我咬着牙重新去寻找解决方案。 过程就又反着来了。
预期目标(秒开75%) -> 可能得到的结果(70 - 75 %) -> 解决方案（提高CSR稳定性） -> 问题根源/痛点(异常率不稳定) -> 根据现状寻找异常（SSR 降级率高）
这里得提一下解决方案的一个点。 SSR并不适合所有页面，且SSR本身就需要成本。 我们知道SSR的优势是可以让你过你省去生存DOM的时间，鉴于此，我们做了两点：
- 就干脆让客户端帮忙在打开页面之前提前获取数据以及静态资源
- 在部分页面中如需打开webview，则打开这个动作延迟一点时间，使其在后台运作。但页面实际上加载完毕再进行跳转（也就是所谓的0渲染时间，实际上是用户感知不到这部分过程。）
开始立项
做完这些后，我们就可以正式开始立项了。以下是我们的立项信息。
投入成本：492 = 480 + 12（UED） 人/日 。 安排前端6人，后端6人，UED 4人， 测试 4人 （研测比3:1） 预估收益价值：总访问量提升 20%，订单提升 10%。（具体多少钱就不透露了）
接下来就需要稳定性平台的监控和预警功能了。毕竟你最终还是需要它来帮你整理出一份数据，支持你目标的数据。然后去向老板要你的绩效吧！
写文不易，掘金目前应该木有具体的项目实践吧 手动🐶 下篇文开始就会涉及 指标的数据采集上报、稳定性平台搭建方面的内容了。 下期见～
（ 我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。 ）
