看到上面的性能情况，我们最先想到的优化方法就是PC时代YAHOO 23条web性能优化军规。
首先看看我们日常业务的请求瀑布图是怎么样的，根据这些情况看那些可以用规则去优化。
请求数优化
- 在请求数控制方面，将js，css各用combo的方式合并成单个资源。
- 页面图片等等，只加载首屏资源，提升首屏展示速度。
- 使用CSS ,SVG,ICONFONT 替换UI图片
合理使用IconFont
iconfont对于前端来说有很多优点：自由变化大小 矢量不失真、自由修改颜色、可以添加一些视觉效果如 阴影、旋转、透明度、兼容IE6。
使用现状
目前大家都基本上从平台上生成，生成后的文件如下：
@font-face {
font-family: "iconfont";
src: url("iconfont.eot"); /* IE9*/
src: url("iconfont.eot?#iefix") format("embedded-opentype"), /* IE6-IE8 */
url("iconfont.woff") format("woff"), /* chrome、firefox */
url("iconfont.ttf") format("truetype"), /* chrome、firefox、opera、Safari, Android, iOS 4.2+*/
url("iconfont.svg#iconfont") format("svg"); /* iOS 4.1- */ }
这样直接引用在项目中，真实在手机上的网络请求如下（在桌面版Chrome浏览器网络中无法看到这些请求）：
这样造成了极大的网络带宽的消耗，这些icon资源往往在界面渲染中占据重要位置。
目前我们移动端只加载ttf一个字体文件，对于较小的文件也可以考虑base64在css文件中。
首屏多个动态接口合并请求
日常的业务中，一个页面往往拆分出多个异步数据接口（后端开发说：解耦），甚至首屏也需要3-5个接口（如动态banner区块，推荐内容，商品列表等），有些还有嵌套关系。
但是这些对页面性能造成不小的影响。
手淘中某个接口在各网络下的请求性能，2G，3G下平均的消耗时间在2-6s完成下载。其中几个请求性能稍差点对整个页面影响也深远。
禁止重定向
在我们CaseByCase的分析中发现，页面&静态资源的重定向会造成巨大的性能损耗。
特别使用前端JS脚本来实现页面跳转的。
图片优化
手淘的特点就是图片多，图片的性能好坏可不仅仅影响用户体验哦，还直接影响着交易，钱 钱 钱…
我们在图片方面做了大量的优化。
使用WebP格式。
手淘2年前已经开始使用WebP格式了（主要native使用），1年前H5全面使用，其中iOS 的webview中由手淘以插件的方式支持。我们以手淘线上真实案例来看使用webp格式的前后效果。
案例为：线上的一个活动页面,打开一看其中的banner 就320多KB，整个页面加载457KB，如果就单单banner图片换成webp格式，整个页面的大小就只有181KB。
使用WebP前
使用WebP后
Banner部分对比
这种业务类型的案例，我们改进一下就可以为用户，为公司省70%的流量费用。
商品图片优化
商品图片在手淘的各个产品中都是必不可少的，为了适应不同业务需求的需要，我们在CDN服务上生成各个尺寸和质量的图片（近100个规格）。
- q值：根据手淘网络情况，加载不同质量的商品图片（q30,q50,q75,q90）
- 锐化：根据需要调整图片锐化值
- DPI：根据设备DPI取适当尺寸商品图片
- 合理的使用CDN图片尺寸可以带来下载图片的性能提升，还可以减少不必要的内存消耗。 我们日常中会用到的尺寸，每浪费10像素的宽高都可以造成很大的内存资源浪费。
计算方式如下：
图片DPI 优化
根据设备DPI值和图片质量Q值做优化，达到最优视觉体验和加载性能（DPI高，宽高增加后可适当降低质量）。
Sprite图片
Sprite图片（又称：雪碧图）被运用在众多使用了很多小图标的网站上。相对于把每张小图标以单个文件的形式引用到页面上，Sprite图片会只要请求一张图片就够了，减少了请求数提升了加载性能，还有就是方便图标管理。但在移动互联网时代在使用Sprite图片需要合理利用，不然反对性能造成影响。
解码内存消耗
Decoded in memory的计算公式： w x h x 4（宽 x 高 x 每个像素4个字节）
如果设备DPI大于1，还需要 X DPI系数。如Retina设备X 4，RetinaHD设备X 9.
禁止生成大图且利用率少
由于图片在浏览器中的解码方式，合理的生成紧凑的Sprite图片，即可以带来更少的请求数，又高性能低消耗。