tmall 前端11.11

体积优化

• 全局图片开关管控，针对商品、店铺、页头、入口图等图片通过开关全局系数裁剪压缩处理，降低页面图片整体体积；

• zCache打包，js和css离线化，减少固定大资源阻塞和请求时间耗损；

请求优化

• 通过全局开关控制，针对走节点懒加载模块图片做域名收敛管控，降低Mobile端的http建连和dns握手的成本；

• 常用图标iconfont化，减少请求；

• 节点懒加载接入，避免非首屏dom载入；

• 空背景图请求修复，避免资源耗损；

• 模块小图片base64化，减少不必要的请求；

渲染优化

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

动态降频(页面渲染wormhole)

• 整个渲染策略就是，定时备份页面到OSS集群，每次请求过来，都会去判断当前系统Load是否过载，若果过载则直接读取上次备份的页面返回，而不使用模板引擎渲染，达到动态降低系统负载，快速响应的目的。 如果发生了最极端的情况，源站全部挂掉，由当天的值班人员，手工切换CDN指向已经备份了的OSS文件，保障页面可访问。

CDN根据终端类型（使用user-agent判断）转发到node渲染服务

模块开发者需要编写一份模块需要数据的 JSON Schema 描述

每一个页面都变成了以下几个部分：

• 一份页面的描述文件，声明了这个页面依赖的所有模块，以及渲染这些模块所需的数据的地址。

• 一系列相互独立的模块。

• 一份包含页面上所有模块需要的数据的数据文件。

node优化

对于 node 应用自身而言，我们首先要保证它有充足的测试，通过 mocha + istanbul ，尽可能让测试覆盖每一个功能点和边缘情况。

• 没有单点 多个节点，主备读取，同时对所有的文件都加上磁盘文件容灾，每一个依赖都不能够出现单点问题

• 弱化依赖 对于每个依赖异常都有容灾的方案

• 预案自动化 对于每一个可能出现问题的环节，都需要有针对性的预案，做到自动化，通过健康检查自动剔除

• 视窗内渲染，就是只渲染可视区域的元素，以减少绘制消耗

• 懒加载，就是图片资源一开始是不加载的，在用户滚动到附近区域的时候才加载，减少网络请求

• 加载限流 限制同时只能加载4个图片，并实时调整加载顺序，优先加载用户当前可见区域的图片

对于多尺寸图片

自动处理图片的gulp任务，可以自动生成多种尺寸的图片，然后压缩、上传到cdn，最后生成一个imgs.js的文件，使用只需要依赖这个js，然后以原始文件名引用即可