这只是小程序用户体验优化的一个小小案例,优化方案也需要根据各位读者自己的实际情况具体问题具体分析。
0x00 源起
这张动图展示的是我们正式发布的小程序“相生一课”点击课程列表项进入课程详情页的加载过程。从点击跳转到最终显示出页面需要 5-6 秒时间。这简直令人发指有没有?大 boss 发话了,用户体验第一位,必须立刻、马上改掉。
嗯,于是我们马上开始排查。
0x01 排查步骤
由于小程序的开发基本是参照官方文档进行操作的,到目前为止也没有什么第三方工具,前端导致瓶颈的可能性被我们暂时排除了。所以我们的第一怀疑目标就到了网络接口上。
1. 接口数据排查
小程序上需要获取到服务器数据以后再进行视图的填充和渲染,网络请求接口返回数据过慢,会导致从跳转到页面显示的过程变慢。
在微信 web 开发工具中打开调试页面,查看 network 标签页。我们发现这个页面共请求了 6 个接口(下图中前两个接口是其他页面的),其中有 2 个返回的数据量比较大,耗时也比较长。
- 课程章节列表,返回 12.7KB 数据,耗时 834ms。
- 课程详情内容,返回 10.2KB 数据,耗时 332 ms。
接口确实很慢。
这两个接口都返回了 10KB 以上的数据,需要考虑减少数据返回。
课程详情内容
现在课程详情内容确实比较多,这需要从内容运营人员那边入手,技术上暂时无法调整了。
课程章节列表
我们发现服务端接口本身似乎是支持分页的,但是现在小程序是一次性获取了所有的课程章节数据。解决方案有了:调整产品的交互方式,章节列表分页加载,可以滑动到底部加载更多,减少每次接口请求获取的数据量,加快接口返回。
2. 业务代码排查
接口上发现了部分问题,可是不对呀。从点击到页面显示等待了 5-6 秒。所有接口就算串行请求也不过 2 秒多,一定还有其他原因。
于是,我们开始检查小程序上的代码实现。
检查接口的请求处理逻辑
进入这个页面发起了 6 个接口请求,如果请求不是以异步的形式发起,那么在同步请求的情况下,所有数据的获取时间会是每个接口返回的时间叠加。如果没有在请求数据返回时就显示相应的视图,而是所有数据都返回时才更新页面。这两点都会造成界面显示出来的时间过长,是用户觉得慢。
以异步形式发起请求
小程序官方提供的网络请求 API 本身是以异步形式执行请求的。大部分小程序开发者应该是以这种方式裸跑的。
我们对其进行了简单封转,每个请求返回 Promise 对象,这样代码书写上多个请求可以组合。书写上确实方便了,但错误使用对导致打包在一起的请求中,返回时间最长的那个会成为瓶颈。
经排查,这 6 个接口是分开异步请求的。
一个接口返回数据以后就处理其相应的视图逻辑
前端视图是需要数据进行渲染的,相关性强的数据可以归到一组。这是接口设计的依据之一,一组数据通过一个接口返回。
从产品设计上看,课程基础数据、课程详情内容、课程章节列表是这个页面最主要的数据,并且这 3 块数据在视图上有明显的区分。
- 页面顶部显示的是课程基础数据。数据量少,接口很快就返回了。
- 课程详情占用一块独立的区域,在第一屏可以看得到。数据量比较大,接口返回耗时。
- 课程章节列表占用一块独立的区域,在第一屏看不到。数据量比较大,接口返回耗时。
我们可以在课程基础数据返回时先显示课程的基础数据;接着课程详情返回时再显示课程详情;但滑动到课程章节区域时,在进行加载并显示。
通过产品设计上的改进,极大缩短了用户看到页面内容的时间。
然后我去倒了杯水,继续...
3. 更进一步
进入课程详情页面的时间确实加快了,但是优先显示了课程基础信息,课程详情的加载还是非常地慢,并且大大超出了接口返回时间。更严重的是,课程详情加载过程中,点击页面上的按钮暂时没有响应。知道课程详情加载完,才出现按钮点击的响应。
这说明主线程发生了阻塞。请求都是异步发起的,莫非请求返回以后的处理出现了阻塞?我们定位到了这两行代码:
var weappDetail = getApp().httpReplace(weapp_detail);
WxParse.wxParse('article', 'html', weappDetail, self, 5);
课程详情内容是富文本格式的,小程序上使用第三方 WxParse
组件进行渲染,在小城官方没有出 <rich-text />
组件前一直是富文本解析与显示的首选方案。经测试这行代码的处理耗时近 3 秒。
罪魁祸首找到了,我们考虑很多方法来优化,最后打算换官方 <rich-text />
来试一下。没想到这一试就停不下来了。
直接上效果图:
是不是如丝般顺滑?我们也一下子变得自信起来!
<rich-text />
使用注意事项:
-
<img />
标签显示的图片是原图大小,可能超出屏幕显示区域。这个为<img />
加上 style 就可以解决了。 - 暂时不支持
<video />
等标签。这从产品、内容上考虑解决方案。 -
<rich-text />
是基础库 1.4.0 以后开始支持的,需要做低版本的兼容。 -
<rich-text />
中的图片无法单独点击放大查看。
目前就这些,其他问题也请读者进行反馈。
WxParse
之所以这么慢,可能是因为我们要渲染的富文本内容太多了,并且其中有大量图片。少量富文本内容时还是可以的。
0x02 总结
这篇文章中发现的小程序加载慢的原因有:
- 网络接口返回数据慢
- 接口响应慢
- 数据传输量过大
- 多个接口没有异步获取数据
- 网络接口数据返回后没有在合理时机更新视图
- 数据解析慢
相应的解决方案:
- 优化接口反应速度
- 减少接口返回数据量
- 列表数据分页加载
- 产品设计上减少必须内容
- 分成多个接口
- 编码时使用异步方式请求接口
- 优化产品的显示逻辑,做相应编码调整
- 使用合适的富文本组件
0x03 写在最后
以上提到的产品用户体验的优化,技术层面可以提升,产品设计层面也可以提升。作为技术人虽然可能比较擅长从技术层面出发,对于产品层面也是应该学习和思考的。
如果你看完本文有收获,欢迎关注微信公众号:非典型程序员(ID:up2048),更多技术干货等你一起学习与交流。
- EOF -