共计 2993 个字符，预计需要花费 8 分钟才能阅读完成。
背景
体验评分 Audits 是微信开发者工具内置的一项性能，会在小程序运行过程中实时查看，剖析出一些可能导致体验不好的中央，并且定位出哪里有问题，以及给出一些优化倡议。
京喜小程序作为京东策略级业务，领有千万级别的流量入口，通过长时间的业务迭代，代码逻辑曾经十分复杂臃肿，有迫切的性能优化需要。因而，联合体验评分性能，以京喜首页做试点，咱们进行了一次体验评分的优化实际。目标是摸索小程序体验评分的指标准则：拿到 100 分的小程序应该是什么样子的；同时心愿借此给我的项目优化提供更多思路。
我会依照「理解首页评分现状，剖析扣分项规定，解决扣分项」这个思路来介绍，就让咱们开始吧～
京喜首页评分现状
关上小程序开发者工具 - 调试器 -Audits，点击运行，操作页面滚一滚点一点，而后点击完结。
评分后果会依据评测页面内容差别、操作习惯、有无缓存有肯定浮动，下图是京喜首页的一次评分：总分 68，性能、体验、最佳实际都有扣分，共计 8 项扣分项，前面咱们来逐条剖析这些扣分项。
扣分项剖析和优化
1、应用了过大的 WXML 节点数目
得分规范：页面 WXML 节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个。
页面节点指标的意义在于，过大的节点数，过多过深的节点组成，都会减少内存应用，款式重排工夫更长，影响体验。
现有节点 2500+，想要进行优化，首先须要理解页面各个模块的节点数散布。
如何统计每个模块的节点数呢？能够应用「控制变量法」，利用性能评测工具中，节点数超过 1000 时会列出节点总数的能力，咱们能够在总指标超过 1000 的状况下，每次暗藏一个模块：
指标模块节点数 = 原总节点数 – 以后节点数
（实测节点数会有小范畴浮动，能够测 3 次取平均值）
首页的模块剖析图如下：
（第一屏）（第二屏）
简化数据如下：
察看列表能够失去两个信息：首页分为展现状态互斥的第一屏和第二屏；列表模块的节点数是大头。
因而，咱们失去优化的两个方向：
- 页面元素按需加载，不展现时不渲染
- 长列表缩小元素个数
第一个优化项能够通过变量管制组件显示暗藏，按需加载卸载。
第二个优化项首先想到的是缩小列表接口分页数值，比方一次申请 20 条数据改为申请 5 条。然而如果接口不反对自定义分页，还能够实现更小的分页拉取吗？
那就本人写一个分页办法的代理吧～
思路如下：
上方为原始申请，每次 20 条数据，下方为代理申请的实现，每次返回 5 条。灰色虚线框是实在的申请数据动作，通过保护一个全量数据，须要哪页取哪页，这是示例代码：
通过以上两个优化，能够胜利的把首页的页面节点数瘦身一下了，最初咱们胜利达到 wxml 节点总数不大于 1000 的指标。
2、存在图片太大而无效显示区域较小
得分规范：图片宽高乘积 <= 理论显示宽高乘积 * (设施像素比 ^ 2)
简略了解是图片尺寸太大而展现尺寸太小，导致节约网络申请工夫和内存资源。
解决方案：cdn 服务商个别都反对通过参数获取不同尺寸的图片，前端能够包装一个公共办法，依据页面元素尺寸拉取适合大小的图片。
此外，补充一下图片体积的内容，除了关注图片尺寸，具体的体积大小其实更值得关注，有以下两个点能够理解下：
- 图片类型的抉择大有文章，jpg/png/gif 还有 webp 应该怎么选呢？先放一张 google 的图
这张图里未思考 webp，加上 webp 其余类型竞争力霎时有余了，挪动端 androd 支持率根本可用，能够思考依据设施类型渐进式应用：
- 利用一些压缩技术对图片进行压缩，png 举荐 https://tinypng.com/，压缩尺寸可观，但对图片显示品质影响甚微。
3、存在可点击元素的响应区域过小
得分规范：可点击元素的宽高都不小于 20px
挪动端操作全靠手指，过小的交互区域会带来不好的体验，能够通过增大元素响应热区的形式来优化，以下形式都能够：
padding- 通明的
border box-shadow
4、对网络申请做必要的缓存
得分规范：3 分钟以内同一个 url 申请不呈现两次回包大于 128KB 且截然不同的内容
这一项的理由是，发动网络申请总会让用户期待，可能造成不好的体验，应尽量避免多余的申请，比方对同样的申请进行缓存。
优化形式：
- 善用小程序的 storage 能力，做好更新和过期治理后，尽可能缓存申请到的数据。
- 针对的确须要屡次申请的日志类接口，能够通过在参数内增加随机数或者工夫戳的形式进行辨别，防止误判。
5、存在短时间内发动太多的申请
得分规范：通过 wx.request 发动的耗时超过 300ms 的申请并发数不超过 10 个。
不同于上一项，这一项关注的是接口并发数：
wx.request（HTTP 连贯）的最大并发限度是 10 个wx.connectSocket（WebSocket 连贯）的最大并发限度是 5 个
优化形式：
- 计算逻辑后移，接口聚合
- 对于职责相似的网络申请，最好采纳节流的形式，先在肯定工夫距离内收集数据，再合并到一个申请体中发送给服务端
6、存在未绑定在 wxml 上的变量
得分规范：setData传入的所有数据都在模板渲染中有相干依赖
这一项考查的是 data 冗余的问题，小程序设计了渲染和逻辑拆散的双线程，两边通信通过 evaluateJavascript 转换字符串再进行拼接实现，须要十分小心两个线程之间通信的数据量。因而，未绑定 wxml 的变量，最好优化成不应用 setData。
依据应用场景，能够做的优化有：
- 与页面展现无关的外部变量，能够挂载在组件实例上，比方保护一个
this.privateData对象 - 应用小程序新版本反对的「纯数据字段」：该字段不会被传递到 wxml 内，配置正则划定它的匹配范畴，能够失常应用
setData办法，具体用法参见文档：https://developers.weixin.qq….
然而，如果你像我一样遇到下面策略无奈笼罩的场景呢？
- 须要批改旧代码，配置纯数据字段的正则影响太大
- 京喜首页应用了 Taro 做多端适配，Taro 编译简单逻辑的数组后会呈现「影子变量」去代理逻辑，本来的数组变量被架空导致扣分
那么还有一个终极 hack 的办法：
这样 list 会被判断为有绑定节点，就不会扣分了
7、发动太多的图片申请
得分规范：同域名耗时超过 100ms 的图片申请并发数不超过 20 个
最初这一项也是图片相干，发动太多图片申请会触发浏览器并行加载的限度，可能导致图片加载慢，用户始终处于期待中。
优化形式：
- 雪碧图
- 图片懒加载：小程序
Image组件反对通过配置lazy-load参数来实现懒加载（https://developers.weixin.qq….），具体断定逻辑是图片进入高低三屏就开始加载。如果须要更可控的实现，能够本人构建组件来解决。
总结
做完这些优化，再测一下体验评分：
以上就是京喜首页在小程序体验评分优化方面进行的实际内容了。
总结一下，小程序性能评分能够从指标和理论数据上给咱们的我的项目优化提供一些倡议，本文次要从评分角度去剖析了各种优化可能，心愿能为各位小程序开发者带来参考价值。
参考资料
[1] 小程序开发文档：https://developers.weixin.qq….
[2] Images: Your easiest page speed win: https://searchengineland.com/…
[3] Tiny Png: https://tinypng.com/
欢送关注凹凸实验室博客：aotu.io
或者关注凹凸实验室公众号（AOTULabs），不定时推送文章。
