不知不觉做好莱坞项目已经一年多了，打从接手后就一直迭代重构开发，新需求新页面的一直滚版本，表面看好像正常进行，其实内部已经有点混了，就在前不久，然后一个同事在群里反馈：



于是乎，一场大扫除来袭了...

开启心爱的YSLOW 评分73 截图如下所示：



前端重构可控的问题，主要表现在：

1、页面图片过多；
2、页面图片尺寸偏大；
3、页面背景图片http请求过多；
4、背景拼图过大；
5、sprite拼图不合理；
6、html dom节点过多。

用WIN8+IE10 检测发现：



内存占用145.6M 导致这情况的罪魁祸首，是i标签，我有一个习惯，习惯把标签角标类挂i当hook，而这个i角标‘会员免费’‘会员用券’恰恰页面出现频率很高，基本每个电影封面都附带一个角标，刚好这张拼图是最原始版本遗留下来的1074x738 46.3k的背景拼图，根据图片占用内存公式：

图片内存占用量=宽*高*像素字节数

1074x738x4 大概3M多，叠加起来就是上面IE10检测出来那值…果断搞定它呗，而且拆分sprite大图过程量比较大，要确认砍掉多余的，合并成小的，并且页面不能有误，所以我将其定为一期优化：

1、拆分sprite大图

将sprite大图逐步打散，不用的删除，目前需要的保留，以页面/模块划分；

2、合并拆分后的小图

合并页面级小图，将稳定不经常改动的图合并成页面级拼图，比如首页为sprite_index.png 会员页sprite_vip.png如此类推，页面模块以mod_xxx.png合并，经常变动，重复率高的抽取后做为独立图片，保证图片低耦合度，按需加载，并且如果该模块后续其它页面也用到的话，可以直接提取到global通用文件夹，灵活度高；

3、用代码代替背景图

删除需要但不必要的图，全部或局部背景图以代码实现，减少背景图的大小体积；

4、文件夹模块管理

文件夹以页面分割管理，文件夹对应页面而建，里面存放页面所需页面sprite以及页面级模块图片，方便提单发布，查找维护；

5、杂

这个点见仁见智，就是杂杂碎的东东，但是归纳不到上面的大类里面，比如我发现首页banner图，星空那张，如下：



中间的区域被轮播图挡住了，其实用户看不到，所以我把它给挖掉，填纯色给它，一下子就少了一半大小，浏览的时候其实感觉一样的。

基本上述优化完毕，完成各个浏览器的兼容测试后，就是激动人心的发布，当然，我保留了为优化的数据截图，以待优化后做对比，优化后好莱坞首页YSLOW评分已经从73上涨到80：



分数变绿，舒服多了，优化后内存占用下降到59M，释放掉100M左右的内存，首页样式背景图大概减少了130K，自己测试OK之后 让基友帮忙测试下：



CPU也降了，至于为什么内存大图片的占用会使CPU100% 这个在网上搜不出结果，我猜是内存里面堆的这150M的内存，CPU渲染页面的时候都会拉取分析，大概平铺切丝图片不要切太小这一类，因为cpu计算量多，效率就低，所以转爆了…

一期优化过后，其实还存在很多可以优化的点，比如：

1、sprite拆分后，背景图片请求增多；
2、电影封面图片过多，预加载策略导致加载资源增加；
3、页面拼图有垃圾图片待整理；
4、dom节点数过多；
5、封面图片缩放。

其中 1、3可以由重构完全控制，所以作为二期的优化重点，2、5需要配合，就作为辅助优化点（此处忽略不详讲）；

正如上述优化所示，我删除了一些已经下线页面的图片，把重复率高的图片抽取成单独拼图处理，比如角标sprite_mark.png，一经 删拆合 之后，发现没有合并很多数量的其实，因为页面还是保留以页面拼图+模块拼图构成，所以合并也只是模块内的拼图合并，模块间的拼图没有合并，基本上可以说页面上有多少模块，就有多少拼图与之对应，所以最后还是有22个图片http请求 略多略多；二期优化比一期的风险就低了很多，而且工作量相比也少了很多，优化效果也就不会很明显：

1：IE10检测 内存从59M下降到46M 降低13M；
2：首页背景图片http请求 25到22 降低 3；
3：图片总大小159k下降到143K 降低16K。

经优化后好莱坞首页YSLOW评分上升到83，其中也许会问为什么不把背景图片合并在一起，这样可以大幅度减少http请求，分数可以上得更高，这点确实是这样，降低http请求是最简单直接的优化方式，不过这样一来，维护更新成本就会变的复杂，发一个小模块的更新要合并成大图后发布，工作量增大；也许你看到这里会说，那就切碎，像gaga那样放slice里面自动合并，但因为自动化了，你不知道哪个icon会被合并到哪个位置，对图片的把控就因此降低，不能准确控制图片，如果频繁迭代，多版本共存的话，问题风险性就会提高，而且图片文件碎片堆在一起，叠多几个版本，确定图片对应的页面，以及必要与垃圾的区分难度加大，感觉会是一个坑，填不了就继续挖，挖到一定程度塌陷了，至于坑到谁，埋到谁，就看谁来接手这个坑了。

至于我现在的处理方式，就像堆积木，样式图片都是一块块零件，螺丝旧了就拆下来换新的，模块旧了就拆下来更新再上，对整体的影响相对较小，模块间耦合度较低，而且因为分文件夹对应页面管理，本地环境条理清晰，管理维护方便，不过正如YSLOW所示，页面模块一多的话，会造成http请求过多，这个是一个 性能与维护之间的权衡，看实际项目与开发者偏重于那一方，没有绝对的。

终上，经过二期的样式重构，分别在 内存占用、http请求、背景图片尺寸、分类管理、代码冗余 等方面对项目进行优化，可计算的优化效果如下：

1、内存占用减少 100M
2、CSS及图片体积减少 140K

还是相当可观的一次大扫除行动。至此优化分享告一段落，由于个人能力有限，还有一些网站性能优化的点，比如CSS3动画对页面渲染优化，图片切割合并优化，等积累一定量素材了再单独写篇文章分享吧，总结一下就是每个站点都是不同的，不可能存在一套万金油的管理优化方案套用所有，要根据实际情况，就像毛爷爷一样，一切从实际出发，根据项目本身的特点，制定合适的方案，强搬硬套只会把自己搞残，带着问题两面性去权衡将采取的方案，尽量保证站点可控。对项目优化的前提是对项目有一定的认知，对涉及页面能把控到位，在此基础上再谈优化，否则失误挨屌了别找我吐槽哈>3<）...如果不是推翻式的整个站点重做，建议分期优化，排布好优化点逐步进行，避免工作量暴涨，否则加班了也别找我吐槽哈>3<）...

感谢大家捧场，又一篇新文章诞生了，真真是十年磨一剑，等的有够久的了，希望文章质量能让大伙儿满意 oh^yeah>3<）...