简单前端优化的实战

最近项目中需要进行前端优化，我们的前端工程师自然就想到了YSlow中经常提到的几条优化前端的金科玉律，特此把部分经验分享之，粗浅表述，权当交流之用，见笑见笑!


　　要优化前端，自然从两个地方着眼，一是减少请求连接数，二是压缩文件尺寸大小。


　　当前项目中使用的是开源的Minify进行合并，这是一个相当亲和的PHP小程序，用还算优雅的方式合并绝大多数复用的JS和CSS文件，并且可以 开启文 本压缩输出的功能，很强大的小工具呢，使用配置起来也是相当容易。如果项目中使用的五六个JS文件合并之后，请求时间基本上可以减少15%~30%，还是 很可观的。


　　图片的请求也是一个很头痛的事情，浏览器是有最大的并行下载限制的(当然你可以手工增大，但是一般用户是绝不会怎么做的)，这时候就需要使用另一个 独立的 图片域名了。把大量的图片放置在另一台服务器上，绑定一个二级域名，之后引用，这样可以容纳更多的并行下载，也有一定的提速效果。


　　有意思的是，项目中使用了被广泛使用的JQuery库，版本是1.4.4，基本满足了日前的需求，貌似mini版本的尺寸是70多KB左右，同时开 启 GZIP压缩对外输出，可以压缩到28KB左右，但是对于我们项目中使用的普通虚拟主机而言，IDC宣称的高速双线其实就是胡扯，在很多地方，一个 JQuery库也需要消耗掉250~450ms的时间。所以我这里使用了Google公司提供的JS库CDN加速服务，道理很简单，就是直接使用 Google公司提供的一个JS地址引用库，利用了Google公司庞大的CDN网络进行加速，何乐而不为呢?


　　示例地址：.yuesir.


　　(编者注:您可以使用Firefox的Firebug插件查看实际加速效果，Google JS托管的效果远比我们的服务器效果好，正常网速下只需要加载150~250ms)


　　当然，这里要注意的是，Google公司的域名在中国大陆经常会被屏蔽或是出现解析错误，为了让我们的服务更加稳定，这里可以做一个JQuery对 象判 断，如果Google的JQuery文件可以正常加载则无事，如果无法加载则换用另一个库，这里我选用的是微软的JS引用，当然最后还是应该把自己服务器 上的JS地址也放置上去。


　　这样，服务的高速和稳定就有保障了。


　　当然，GZIP是一定要开启的，大有裨益啊!


　　话说回来了，由于使用了Minify的合并以及自动精简，我已经不再剔除掉JS代码和CSS代码的注释了，这样不仅仅方便了工作，更是对项目的可维护性有很大的帮助。


　　在假设图片服务器的事情上，我还是持着开放的态度，尽量使用第三方资源，而把精力放置于核心的业务逻辑。所以最后我并没有使用自己搭建的方案，而是使用了国内相对优秀的图床服务供应商"又拍"的VIP相册管家。


　　主要看中的是它支持FTP自动导出备份，自定义域名绑定以及比较稳定高速的网络带宽资源。


　　对于第三方服务，还是得有一种开放的态度呢，不然把很多的精力放在了无关的事情上，是得不偿失啊。


　　话说等到服务稳定了还是得通过FTP备份下所有的图片，之后重新改名，并且进行目录归档管理，方便项目自主稳定的升级。


　　当然在前端上的优化是无止境的，项目中还是用了一些优化的方法，下举一例：


　　使用了JQuery库插件Lazyload，凡客诚品、初刻之类的都在使用(话说昨晚发现初刻前端的一个严重问题，心里很开心)，淘宝也自主编写了类似的功能库。这个插件的功能就是可以使视界之下的图片文件无法读取，当滚动条滚动到图片处，才开始读取。


　　这样按需加载的方式很有效果，目前已经被大量使用了。只是有一个问题是，图片需要有默认的高度(他是通过计算图片高度来运作的)，不然会出现抖动、无法按需加载的Bug。


　　当然官方提供的Lazyload只是一个障眼法，如果你分析HTTP请求就知道，本质上原生的Lazyload并不是真正的按需加载，而是障眼法罢了，所有的图片依旧照常发出请求，只是用户暂时看不到罢了，之后用一个fadeIn呈现。


　　我们只需要做一个很小的改动就可以了，欲知详情，可以搜索"lazyload 改进"就可以了解到改进方案，真正的实现按需加载