引言

我在刚入行那年，第一次参加内部团建的时候，我对着领导大放厥词：“老大，你有没有感觉咱app上那些h5页面都好卡啊！随便点个入口进去明显感觉要等好久……”

当时一个大组里有几个小组，总共37号人。我就借着酒劲当着所有人的面“胡乱诋毁”他人。其实是我年轻气盛不懂事，现在想想简直是社死现场。

第二天到公司，老板叫我进了小黑屋。故事也就从此拉开了前端这条路的第一次序幕……

原来能被接手的都是烂摊子

从小黑屋里出来，我脚底都是漂浮的。没办法，自己吹的牛跪着也要崩住了。

关于性能瓶颈的普遍问题

小黑屋里也不是什么都没收获，领导很认真的给我说了一下目前公司遇见的一些疑难杂症。有以下几条。

• 页面打开慢，例如点击商品标签跳转到详情页的时候，白屏的时间有点长（能清晰的被用户感知到慢）
• 唤端失败率很高，以至于目前都放弃了从外链唤起app到达目标页面的功能。
• 老板不知道咱做的功能好还是坏，全靠实际的下单量、客单价、毛利来做评判（总之就是赚钱多少）
• 活动页更新迭代很慢，一到大促就需要技术疯狂加班……

你看，做老板的都是直切要害，告诉你现在遇到的瓶颈。 但是，没有人教我怎么做。你没办法很顺利的直接将老板的话变成技术瓶颈。 这都需要你去分析去看。

作为一枚初入行的菜鸟，即羞涩又恐慌，导致即不敢问，也不敢说自己不懂（死要面子）。遇事不决先观察，我曾经是美术生，写生的时候第一件要认真做的事情就是观察花草树木人的每个细节，然后才能决定如何下笔。

我大概花了1个星期多一点时间，去勾搭各个部门的人，一副我对谁都有兴趣的样子（后续渣男的绰号也由此而来）。

1. 我从数据团队那边要了份简易的用户行为数据，大概了解到高流量被分布在哪些时间段，对哪些业务比较敏感。
2. 从客户端那了解了如何与h5页面打交道的
3. 从基础服务、部署平台那边了解了前端h5项目的整个编译打包部署流程

得出初步结论：

1. 流量大的页面，例如大促活动页内容太丰富了，没有主次之分。

2. 打包后的bundle.js 体积太大，不利于页面加载资源。

2. 异常率较高，页面报错、接口异常、白屏次数多。

尝试有效解决方法

脑瓜子疼。知道得越多，脑瓜子越疼。 这才2016年（当时是2016年），为什么我这个菜鸟要承受生命不该承受之痛苦。

我勾搭了一个客户端的小姐姐（我发誓，纯技术交流），也是最耐心最好沟通的一个。当时她提醒过我一句：“你为什么不做缓存呢？我们webview都是活着的。”

我让小姐姐给我打了个测试包，给我提供了一个方法能直接去更改缓存的方法。我只剩那么一试，我仅仅只是将一个不复杂页面的HTML 和 css 单独抽出来，直接写死到缓存里。然后那个页面 "chua~" 一下就出来了，虽然只是个静态页面，但这说明我的路子可能是对的。这样，我就开始想着有哪些东西是可以放到缓存或者交给客户端帮忙解决的。

很快，小姐姐又给我来了个透心凉：不要想着啥都放缓存，缓存有限制的，而且活动页辣么多……

我忽然间意识到，也只有商城首页才最有资格去使用缓存。比较首页的资源才是最多的，其中最重的就是图片了。那时候有去扒拉某淘的页面是怎么处理资源的。 惊奇发现打开某淘的活动页，内容已经都看到了，但有些请求缺还在发。最关键的是一些图片资源url 是.webp

所以初步总结下

1. 图片是大头，首页的图片可以放缓存。尽量都处理成webp格式

2. 浏览器缓存配好

3. 非首页尽量做到少加载资源，或者不重要的资源延迟加载

4. 接口也是个大头，关键接口也可以做个预请求

分析一下不同点的解决方案实现难度

图片问题好说，没啥大的技术含量，转下格式，做好图片缓存。 首页静态资源也好说，毕竟是首页，有充足的理由去和客户端那边进行沟通。

问题是非首页的问题咋搞。即使做了延迟请求、延迟加载，依旧还是差了些意思。这时候，我心里已经有些底了。我去找我的领导说：“我们能不能搞一个node服务，搞SSR。”

现实狠狠打了我的脸。

1. 你知道申请一台机器要花多少成本吗？

2. 你能保证这个服务稳定吗？

3. 你一个人搞不定吧？ 现在资源有些紧张……

其实有预料到这样的结果，别说老板了，全公司估计也没谁会轻易的相信一个刚入行的菜鸟萌新，况且也暂时拿不出能让领导们认可的技术方案和可预测的结果。

关于SSR 的替代方案，倒是想了个窍门，就是让客户端打开webview 的时候也做一个延迟。 简单来说就是webview已经打开了，但是延迟一点时间跳转到h5页面。

以现在的眼光看待曾经的问题

很明显，现在已经老掉牙的h5性能优化的几个点： 懒加载、缓存、离线包、并行化 ……

现在的知识点已经很多很丰富，现在网上资料一大堆。 以现在的角度来讲，手段并不难，难的是如何根据实际业务场景去作出合适的选择。 公司必然会考虑 成本、投入产出问题。

这时候你可能需要清晰的了解到，哪些页面是需要做到秒开的，或者秒开率要达多少。那从赚钱的角度来讲，千万级流量的页面强网秒开要达80%，弱环境达50%。 百万级流量……

那话又说回来，当你把页面秒开做的足够好了，你又该怎么证明呢？ 或者说你该拿什么来像老板证明你达到了要求呢？ 老板需要你用准确的数据、可视化的图表来清晰直观的表达结果是怎样的。

老板的要求其实划分一下就两点：

1. 快、流畅

2. 稳定

至于老板能赚多少钱，剩下的问题就是业务和产品的问题了。

关于下篇文要讲的稳定性平台

可能会有人问：稳定性平台干嘛的？

给个准确定位的话，大概有几点：用户画像（用户行为）、异常概况、告警、容灾

根据字面意思其实就能很清晰的了解。 你要知道用户干了什么， 如有异常（js异常、服务异常、白屏、卡顿等）要及时告知相关责任人，并进行告警。容灾，如果线上万一哪个环节出了问题（尤其是大促场景流量很高的时候）能及时回复至上一个正常状态。

下面先放在简陋的图：

一个项目通常都会经历 需求 -> 开发 -> 测试 -> 预发/发布 -> 线上运行 几个阶段。 不同公司之间的区别也就是在不同阶段中规范标准的不同。但毫无疑问的是，必须要先保证线上运行阶段是正常的，然后才有必要去谈其它阶段。 其实图中要仔细画的还有很多， 下篇文重点讲一下稳定性相关内容。