天猫活动页面的性能优化

Question

数据结果

无线优先从去年开始推行，今年更是全面无线化，双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 端技术的一致性和简单性，提高工作效率和工程化能力。而这在全面无线化的今天，已经成为一个瓶颈，这也是天猫后续技术发展需要解决的一个非常重要的问题。

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