前言

为什么得说“性能优化体系”，而不是方法或者结果导向？

现在太多的人都对【性能优化】这个话题有所了解。 我们来尝试回答一下下面这个问题。

你是如何做性能优化的？

答案1： 优化资源，懒加载、缓存、接口请求优化……（老套筒，没意思）

答案2: 借用浏览器提供的一些工具来衡量一下页面时间，围绕首屏或者首屏秒开做点文章。

答案3: 需要一个具有诊断功能的性能平台来精准的诊断下页面的情况（这问题就大了，涉及到性能平台怎么玩）

答案4: 根据实际情况，搭建性能优化体系，从系统层面来考虑如何作优化的事情。

所以，你是属于哪种答案？

所谓“体系” 是你对现状的一种集成与牺牲

你是否应该先了解公司靠什么业务赚钱，然后看看能不能定制出一些能让业务更赚钱的体系来？ 假如你的体系中制定了指标A，指标A 达到某个数值就可认指标A完成目标。 那由于指标A能让公司业务变得更加赚钱吗？

如果指标A能，那说明指标A是有效的。如果不能，那说明指标A是无效的。举个简单的🌰，行页内电商类APP都在乎秒开这个指标，因为秒开率越高，留住用户的可能性就越高，提升下单转化率效果就越好。 反正，游戏APP（例如王者荣耀、吃鸡），秒开这个指标还重要吗？ 它就没那么重要，因为玩游戏的都愿意等个几分钟，怎么还会在乎你1秒。

所以，先确定你的体系里需要存在哪些指标，再缺制定衡量这些指标的方法。 这个过程就叫集成。

那么，啥叫牺牲？你的体系里其实有很多必要性很强的指标，但是需要先投入成本再经过一段时间才能有产出。换句话说有些事情你不一定来得及做，做了不一定能被老板接受。

所以你有 一个成熟的体系，这个过程还叫做 牺牲。

体系

一图胜千言，先上图。

看完图，你在想想，现在你会如何回答哪个问题：你是如何做性能优化的？

1. 性能优化流程 - 直接行为

开工第一步，先制定指标。

这里有个依据，不能想当然，毕竟最终是要写代码的，所以：

1. 尽量能用代码解释

2. 能被数学解释

3. 能直观衡量用户体验感受 或者 服务优劣

4. 能被老板理解并接受

接着，为你的指标制定标准。 举个两个🌰，

1. 秒开指标。 标准是 所有活动页强网秒开率要达 70%，弱网要达30%。
2. 降级指标。 标准是 SSR降级率不能高于5%，大促页面降级率不能高于7%。

（我觉得你看懂了）

通过事前预估达成结果后的收益决定做哪些

这里就不多解释了。最重要的还是情商的活儿。 毕竟你也要从老板那那kpi考核的。

根据现状诊断病因

请搞清楚以下几点：

1. 病多久了，是否病入膏肓（这决定你是要重构/优化 系统 Or 业务）
2. 为什么病这么久 （你要了解为什么病这么久还能活，能继续活多久）
3. 客观病因 （确定是业务差 还是产品营销策略有问题，或者是没钱）

这几点搞清楚了，你再判断是 【快】 、 【稳定】 哪个因素是掣肘你前进的根源。如果两个都是，emm，任重道远。 【快】 是指页面到达快，秒开率高，交互顺畅。 【稳定】 是指异常率维持稳定。

找回你曾经了解过的优化手段

虽然是老套筒了，但还是说一下，点到即止

1. 优化资源。 图片、打包后的bundle体积……
2. 缓存。 接口缓存、http缓存、资源缓存
3. 延迟加载。 也叫懒加载。 重要的内容先加载、渲染。不重要的往后排。
4. 预加载/请求。 这点一般需要客户端写协作。 请求接口和获取页面静态资源由客户端提取完成，这样能节省页面请求资源和接口的时间。
5. 离线包
6. SSR
7. ……

保持线上追踪

这里的追踪，如果你指做完了性能优化的一个流程，那追踪大致上是需要人肉工作的。例如实时去盯住一些交易量、下单量、客单价……

但是如果做了监控告警功能，就不需要人工太繁琐的介入了。 这个后面再讲。

逃不过的首屏时间

好吧。不得不承认，你要做性能优化那肯定逃不掉首屏时间 这个词了。 那些拗口的英文单词我就不叙述了，自行搜索即可。

首屏时间=白屏时间+渲染时间。从浏览器输入地址并回车后，到首屏内容渲染完毕（用户能开始进行交互）的时间。

有人问过，为什么会出现白屏的现象？ emm， 毕竟页面是从无到有的过程，那从无到有总得有个过渡时间。 白屏的原因有很多。 客户端启动webview 需要时间，根据经验这个时间很难优化，大约在150-200ms 时间。 如果你需要在渲染内容之前去发请求获取一些资源或者数据，那又会造成不可控的时间问题。 额外的还有离线缓存没做好，首屏内容太多，又或是网络情况不好 ……

所以，白屏时间是必然存在的。重要的是，你选择让它白多久，又让它在什么时候白。

渲染时间就相对简单些。 浏览器渲染进程去渲染首屏DOM。

但首屏时间 意义就比较大了。 我是电商背景，首屏的商品图、价格以及提交下单按钮是无论如何也要保证用户能看见的。 例如大家都经历过双十一抢购，最关键就是加车、下单按钮。

说这么多，如何计算首屏时间呢？ 放心，肯定能计算，不过这个适合在数据采集上报那一步做。这里就先给个首屏时间的标准，仅供参考。

类型	首屏时间	秒开率	1.5秒开率	2秒开率
SSR	1000ms	70%	90%	95%
端外	1500ms	35%	50%	75%
端内	1200ms	65%	80%	90%

立项

你纠结了那么多，调研了许久，搞了不少事情。 总得最后来个立项吧？我简单分享一下我曾经立项的经历。

立项流程

项目立项就是成立一个项目组，整个项目组来解决问题达到最终目标。立项流程包括：

1. 团队成员确定 （不可能你一个人单干，需要团队合作和跨团队协作）
2. 技术调研开展 （分好子目标或者子任务，然后各自去调研）
3. 项目目标制定 （根据调研结果，清晰明确的制定各个阶段的目标）
4. 获取业务方支持 （用你的诚恳和关怀打动（忽悠）住业务方，比较业务爸爸惹不起）
5. 需求范围和优先级确定等过程。（这个关系到具体的测试、产品、UI验收等问题，所以还是要很细致。）
6. 项目名称就一般用达成目标或者问题描述来起即可。

项目目标制定

有道是根据现状寻找解决方案，最终得到一个结果，而这个结果是希望符合预期的。那么这个过程就是：

根据现状寻找异常 -> 问题根源/痛点 -> 解决方案 -> 可能得到的结果 -> 是否符合预期目标

初始的预期目标是 首屏秒开能达65%，站外秒开率能达20%。 这个目标其实算比较低了些，但……（你懂的，一步步来嘛）。

后来吧，感觉老板可能对这个目标不会太满意。 我说服老板先一步一个脚印（直到偶然有一天听见老板跟另外一个人吐槽 我能力不太行）。 于是我咬着牙重新去寻找解决方案。 过程就又反着来了。

预期目标(秒开75%) -> 可能得到的结果(70 - 75 %) -> 解决方案（提高CSR稳定性） -> 问题根源/痛点(异常率不稳定) -> 根据现状寻找异常（SSR 降级率高）

这里得提一下解决方案的一个点。 SSR并不适合所有页面，且SSR本身就需要成本。 我们知道SSR的优势是可以让你过你省去生存DOM的时间，鉴于此，我们做了两点：

1. 就干脆让客户端帮忙在打开页面之前提前获取数据以及静态资源
2. 在部分页面中如需打开webview，则打开这个动作延迟一点时间，使其在后台运作。但页面实际上加载完毕再进行跳转（也就是所谓的0渲染时间，实际上是用户感知不到这部分过程。）

开始立项

做完这些后，我们就可以正式开始立项了。以下是我们的立项信息。

投入成本：492 = 480 + 12（UED） 人/日 。 安排前端6人，后端6人，UED 4人， 测试 4人 （研测比3:1） 预估收益价值：总访问量提升 20%，订单提升 10%。（具体多少钱就不透露了）

接下来就需要稳定性平台的监控和预警功能了。毕竟你最终还是需要它来帮你整理出一份数据，支持你目标的数据。然后去向老板要你的绩效吧！