这份文字是根据近期团队做来问丁香医生 SPA 和 丁香医生小程序 加载速度优化（optimalize）的 经历整理而成。效果古人有一句话叫做：治感冒看疗效。既然是关于速度优化的 ，我们就先来看一下优化的 效果。来问丁香医生Chrome Network ..
这份文字是根据近期团队做来问丁香医生 SPA 和 丁香医生小程序 加载速度优化的 经历整理而成。
效果
古人有一句话叫做：治感冒看疗效。既然是关于速度优化（optimalize）的 ，我们就先来看一下优化的 效果。
来问丁香医生Chrome Network
选取了访问量较大的 首页和页面进行随机取样，通过下图可以看到首页的 加载时间从 5.1s 下降(descend)到 1.67s，页面从 2.92s 下降到 1.82s。
宁波小程序开发对于用户来说，能够节约使用时间成本和手机内存空间；对于开发者来说也能节约开发和推广成本。
mta
2018.01.02 早上的 页面响应速度数据，目前国内各省份平均加载速度在 0.99~2s（虽然没有达到 1s 内加载，但是以目前业务量级，这样的 速度是可以被接受的 ）：
前者这是 Google 的 一个评分工具，最开始做优化时用它测了一些页面的 分数。宁波小程序开发对于用户来说，能够节约使用时间成本和手机内存空间；对于开发者来说也能节约开发和推广成本。后来发现了后面这些 Chrome 插件。让我困惑的 是同样的 页面这几个工具给出的 结果分数都不一样。手淘 的 首屏加载速度挺快的 ，但是跑出来的 分数也不高。最终我只是选择性的 参考一下工具给出来的 建议，忽视了其给出的 评分。
丁香医生小程序
对于小程序，做了优化后得到部门同学的 反馈是这样的 ：
具体的 数据指标如何呢？虽然目前没有特别好用的 性能检测方式（包括官方提供的 性能检测工具在内），最终我们组的 舒哲同学还是利用官方提供的 工具做了一下简单的 数据对比，数据如下：
在不影响产品(Product)需求正常迭代(更替)的 前提下，两个的 优化断断续续持续了两周。整体上来说，本次优化的 性价比还是较高的 。
为什么做加载速度优化？
直接原因很简单：慢。虽然说页面加载速度并没有达到慢的 让人没有办法忍受，但至少没办法让人说加载很快。
既然明知道加载速度不快，那之前在干什么？为什么不早早的 去做优化呢？
这是一个好问题，我曾经在深夜中问过自己多次。我给自己的 答案是：首先，要承认自身技术水平和经验的 限制，如果是一个在前端战场上身经百战的 人一直在负责的 迭代，或许情况会比优化前好一些。 其次，之前整个产品(Product)线的 一直处于探索和快速迭代中，前端研发有精力来做一些优化。
为什么说是前端响应速度优化，而不是前后端？
因为我是亲眼看着这两个逐渐长大的 ，单从前端工程的 角度来审视，在自己的 认知范围内，早就认为中有一些地方是需要优化的 。坚定了先从前端动手的 想法，是因为读了《高性能网站建设指南》这本书，书中提到了一个性能黄金法则（Performance Golden Rule）：只有 10% ~ 20% 的 最终用户响应时间是花在下载 HTML 文档上。话说到这个份上，还犹豫什么呢，先从前端开始撸起袖子加油干吧。
之前去 Qcon 等技术大会上，听过几次关于加载速度的 分享。比如：使用 HTTP2，整站级别的 前后端优化等。方案确实是好的 方案，但具体是否要应用到自己团队实际中，还得根据执行成本、团队技术储备等维度从长计议。
为什么说是初级？
因为深感自己在前端性能优化这个领域还有很长的 路要走。
如何做的 ？
前戏这么长，终于可以开始了。
来问丁香医生 SPA
先看图（绿色部分为已在中应用的 方法）：
实现游客机制
最初来问丁香医生是基于微信服务号做的 ，当时的 设计是用户通过服务号菜单进入应用时，会自动帮他进行跳转登录，登录成功后服务端再重定向回到应用。登录这个环节，虽然与代码层面的 加载优化关系不大，但是从用户体验的 角度这样的 流程是不好的 。因为相比于直接打开页面，用户需要等更长的 时间，并且会看到两次页面加载的 进度条。从产品(Product)的 角度，一些页面是不需要用户登录即可访问的 。综上，将登录流程后置，让用户可以直接进入应用这件事情，于情于理都是必须要做的 。
改造流程大致为：梳理产品现有流程 -> 用户进入应用时取消强制登录 -> 在产品流程核心环节进行用户登录状态判断并引导登录。宁波小程序开发对于开发者而言，小程序开发门槛相对较低，难度不及APP，能够满足简单的基础应用，适合生活服务类线下商铺以及非刚需低频应用的转换。具体实现细节不再赘述。
减小包动手了。因为通过 Chrome 开发者工具的 Network 可以看出，下载 CS
S、JS 包体积（volume)之前的 情况：
优化前包体积大小-Gzipped
精简第三方依赖
想要减少时应该/可以被删除的 。由于是基于 Webpack 构建的 ，因此可以使用 Webpack Bundle Analyzer 进行分析Webpack 生成的 包体组成。然后根据实际情况进行移除就好。
精简了第三方依赖后，启动应用时需要下载的 包体积大小
Gzipped：
用户进入首页需要加载的 js
最开始做小程序时，是把所有图片最终都被打包到小程序的 安装包中。所以做小程序的 加载速度优化的 第一步，就是把一些体积较大的 图片。具体做法是将素材先上传到 cdn，然后在小程序中直接使用线上图片。
登录鉴权优化（optimalize）
原本小程序的 登录是我们自己实现的 一套登录方案，核心是前后端一起维护一个类似于 SessionId 的 ID。服务端对于这个 ID 是设置了有效期的 ，而之前前端的 实现是每次用户启动小程序，都直接去请求公司的 SSO 获取一个新的 ID，没有在意本地的 ID 是否过期。
优化的 点在于在应用启动时，增加对 ID 有效期的 判断，从而避免每次用户启动都需要发请求获取新的 ID。
预渲染
之前在小程序所有需要从服务端获取数据的 页面，都实现了一个加载中的 效果，即请求未返回结果时，整个页面用户只会看到一个加载中的 菊花。如果某页面只有服务端提供的 元数据级别接口，没有业务接口，并且接口返回的 数据是有依赖关系的 ，那么用户等待的 时间会大大加长。
仔细思考会发现，其实是没有必要等所有接口数据回来后再给用户呈现完整页面的 。
最终的 优化方案分为两种：一种是取消加载中效果，先给用户呈现完整的 利用本地数据渲染好的 页面，等接口返回数据后在进行页面视图的 更新；另外一种方案是取消加载中效果，但是不做本地数据渲染，而是直接给用户看到部分静态页面。
分包加载
关于分包加载，就老老实实的 按照官方文档做就好了。进行分包后的 效果还是很不错的 。具体效果可以参考文章开头的 数据统计。
目前上述方案中，效果比较明显的 是预渲染和分包加载。一个是视觉上让用户觉得快了，一个是真真切切的 把首次加载的 资源包变小了。
