数据结果

无线优先从去年开始推行,今年更是全面无线化,双11无线业务成交拿到了不错的结果,性能也迈出了一大步,对比去年双十一页面整体load时间提升了2s秒左右,秒开率达到了70%;

去年双11活动会场埋点几个页面的性能,onload均值在4.7s左右(实际情况应该在3-4秒),导致跳失率非常高。

今年双十一后的数据情况:

2G平均加载完成时间 3G平均加载完成时间 4G平均加载完成时间 Wi-Fi平均加载完成时间 wifi页面秒开占比
4s 4s 2s 2s 70%

做了什么

体积优化

  • 全局图片开关管控,针对商品、店铺、页头、入口图等图片通过开关全局系数裁剪压缩处理,降低页面图片整体体积;
  • zCache打包,js和css离线化,减少固定大资源阻塞和请求时间耗损;

请求优化

  • 通过全局开关控制,针对走节点懒加载模块图片做域名收敛管控,降低Mobile端的http建连和dns握手的成本;
  • 常用图标iconfont化,减少请求;
  • 节点懒加载接入,避免非首屏dom载入;
  • 空背景图请求修复,避免资源耗损;
  • 模块小图片base64化,减少不必要的请求;

渲染优化

  • gif动画去处和部分模块高度计算有误兼容避免引起重绘性能耗损;

为什么这么做

体积优化价值

对比去年双11和以往活动提升最明显的地方在于,针对所有图片均作了裁剪压缩处理,由于活动业务的特殊性,和目前在源头没能控制住图片的大小,往往一张页头图片或运营从detail页提取的商品图片就能达到300k,整体页面体积能超过1M(首屏600k左右),而现在通过CDN的裁剪压缩后一张图片大小能缩小70%左右,针对所有图片处理后页面整体体积和效率缩减至少一半,以一个简单双十一页面为例:

  • 压缩处理前,首屏体积520k,finish时间5.83秒
  • 压缩处理后,首屏体积315k,finish时间2.87秒

预加载是这次手淘新发起的解决方案,将页面中静态资源预加载到手淘客户端,减少这些静态资源请求,这套方案也正好解决了,天猫目前繁杂的业务下诞生的一些固定大资源的问题。详细会在相关文章中再详细介绍

请求优化重点

  • 域名收敛:在无线端http建连和dns握手决定资源加载速度,cdn域名分发方法反而不适用,同时手淘httpdns服务在启动的时候就会对白名单的域名进行域名解析,返回对应服务的最近ip(各运营商),端口号,协议类型,心跳 等信息,使用收敛后白名单中的域名,在手淘下返回会提升资源加载速度。
  • 图片base64和iconfont合并:很多常用小图标大家针对自己模块都做了合并或单独处理,这样带来的问题是模块搭建完页面后,需要花费不必要的时间加载图片,无线下那怕一张0.5k的小图片,也可能会花费1s的时间去请求,影响页面的load速度。
  • 空白请求的去除:模块换肤中很多背景图片,使用的空请求,实际上空请求也是会花费请求时间, 空白请求也会耗费时间。

优化中的痛点

  1. 由于目前预加载无法解combo,而造势、预热期间模块发布比较频繁,影响预加载后的命中,特别是全局模块,直接会导致页面升级发布后失效(无法命中),无法作为长期方案
  2. 脚本体积过大,目前基础脚本文件大小在100k上,占了我们规范标准的一半以上体积。

关于体会

目前天猫的页面基本上都还在基于KISSY搭建,原来的目的是为了保持PC/Mobile端技术的一致性和简单性,提高工作效率和工程化能力。而这在全面无线化的今天,已经成为一个瓶颈,这也是天猫后续技术发展需要解决的一个非常重要的问题。

性能这块活动目前做的远远不够,看向手淘,还有太多太多的东西要做,相比繁杂的业务压力,确实需要缓缓,放慢手中的业务,将性能和品质提升上去。