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,然后以原始文件名引用即可