数据结果
无线优先从去年开始推行，今年更是全面无线化，双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速度。
- 空白请求的去除：模块换肤中很多背景图片，使用的空请求，实际上空请求也是会花费请求时间，
空白请求也会耗费时间。
优化中的痛点
- 由于目前预加载无法解combo，而造势、预热期间模块发布比较频繁，影响预加载后的命中，特别是全局模块，直接会导致页面升级发布后失效(无法命中)，无法作为长期方案
- 脚本体积过大，目前基础脚本文件大小在100k上，占了我们规范标准的一半以上体积。
关于体会
目前天猫的页面基本上都还在基于KISSY搭建，原来的目的是为了保持PC/Mobile端技术的一致性和简单性，提高工作效率和工程化能力。而这在全面无线化的今天，已经成为一个瓶颈，这也是天猫后续技术发展需要解决的一个非常重要的问题。
性能这块活动目前做的远远不够，看向手淘，还有太多太多的东西要做，相比繁杂的业务压力，确实需要缓缓，放慢手中的业务，将性能和品质提升上去。
天猫前端团队招聘
如果你看了这篇文章，对加入天猫前端团队有意向的，可以发简历到join-tmallfe@list.alibaba-inc.com，招聘要求见：job.alibaba.com/zhaopin/pos…
