项目到了后期，功能是都实现了，然后就出现了KPI（Key Performance Index 关键性能指标）不达标问题。
首先想到的是图片，因为所负责的网页有大量的海报，表现最突出的就是海报一张张加载，有的超大型海报还是慢慢展开的。这样的用户体验非常不好。所以，必须在海报清晰度和大小之间做个平衡。在经过与测试沟通后他们就只去掉了一张500KB的海报，还是剩下了好多90KB、60KB的图片。我感觉这些还是有些大。因为我记得我们为了减少http请求会用Sprite图片，这种图片是最好不要超过50KB的。这也是为了提高用户体验。最终没有和测试撕成功。好嘛，你们就想说我代码有问题嘛。对的，是有问题！
通过分析代码耗时，得出最耗时间的就是请求接口数据。80%（估算，甚至更多）的时间都耗费在了这个上边。我们前端能做的就是去掉不需要的请求字段，减少请求。剩下的就是接口能力问题，无能为力（有同学的做法是自己用原生的ajax请求，放弃框架中封装好的请求接口，因为我非常懒，所以我不太喜欢这种做法）。
好嘛剩下的不到20%的时间用在了我们自己的代码上。这时候《高性能JavaScript》就登场了。好了现在正确的姿势是关闭此文章，然后找到这本书，开始看吧。因为以下纯属个人为了记忆而写。
其实性能优化，尤其是代码层面的优化应该在我们一开始写代码的时候就考虑到，而不是等项目结束的时候才说这个。因为这个时候优化代码有可能会造成自己都难以测到的bug。个人感觉在项目后期保持版本稳定比较重要。
1. 脚本位置。JavaScript放HTML文件末尾，</body>之前。因为JavaScript在加载和解析的时候阻塞了其他文件的加载。书中还推荐了用非阻塞方式、动态方式加载JavaScript，个人比较暴力，所以采取放末尾方式。
2. 脚本个数。合并脚本，减少脚本个数。同样适用于图片、CSS文件。下载一个100KB的文件比下载4个25KB的文件要快。我没测，默认认同，哈哈，好任性。
3. 数据访问。访问数组项和对象成员比访问直接量和变量要慢。局部变量比域外变量要快。所以，对经常使用的数据项、对象成员和域外变量，都用局部变量缓存，这样又可以节省一点点性能。当然这相对于加载一张变态大的图片来说微乎其微。但这是一个优秀的编码习惯，还是get起吧！
4. DOM编程。减少DOM访问，对于经常访问的DOM元素做缓存。减少重绘和重排，动画使用绝对坐标，离线操作DOM。使用事件托管，最小化事件句柄数量。
后边的章节还没看。估计会有什么时候用for、for-in、while、if还是switch这些。希望在两个星期内把这本书看完。
哦，对了，这个页面还有一个影响KPI的大问题就是透明背景层。因为机顶盒能力问题，应用里边用了两个整的透明图片作为背景。去掉这两个PNG透明背景，速度有很大提升。但是肯定不能去的啊。所以我们的KPI小组长就让我尝试了一种方法，使用transform:translate3d(0,0,0);，我查了一下，这样做的目的主要是想通过运用translate3d的第三个参数开启GPU硬件加速模式，详细请看使用CSS3开启GPU硬件加速提升网站动画渲染性能。
暂时想到这些。
好，The End。