随着WEB2.0时代来，给网络的带来了空前的发展。前端用户体验变得越来越显的重要，从而来弥补B/S结构的用户交互型差的一些弊端，可是这样会带来一个问题就是会增加客户端的压力，比如大量运用JS代码，大家都知道JS代码是运行在客户端的，会影响到整个网页的在浏览器的解析效率，这样也可能暗示着会增加客户端的流量，所以不管是从服务器负载角度还是站在用户的角度来看，对客户端的代码进行优化都显得尤为重要！本文主要内部和外部两方面来阐述WEB前端优化的方法。希望能给读者一些体会和启发。
首先，我们通过一个雅虎的统计图表来看看打开http://yahoo.com的http的流量数据：
我们可以发现一个页面的从第一次发出服务器请求到完全载入到客户端的过程中，读取html代码只占了整个响应时间中的5%，这个结果适 用于绝大多数网站，在采样美国的前十位网站中，只有一家超过5%但少于20%，其余80%的时间是用来读取网页其他内容的，也就是说，前端（原文是 front-end，意思就是不包括html代码的其余内容，可以是图片，脚本，flash，视频，各种东西）。这就是为什么我们要把目光集中在这些东西 来提高显示速度的关键原因。
为什么要从前端开始着手有三个主要原因：
这里有提升和改进的潜力。如果能减少一半的体积，就能减少40%的响应时间。
改进前端比改进后端需要的时间和资源更少。（改进后端要重新设计应用程序规划，代码，寻找优化代码的方法，添加或改变硬件配置，分布式数据库，等等）
我们的黄金规则是：首先优化前端表现，这些东西耗费了用户端响应时间中的80%。
一、从代码之外，咱们有以下三种方法
1.运用cdn技术
具体方式，可以Google一下。（大体的原理好像就是判断访问者的位置及访问的内容从而来选择就近的服务器来处理用户的请求）
2.加一个长时间过期的头部
Expires: Thu, 15 Apr 2010 20:00:00 GMT
浏览器会用缓存来减少http请求数来加快页面加载的时间，如果页面头部加一个很长的过期时间，浏览器就会一直缓存页面里的元素。
不过这样会带来一个问题，就是如果页面里的东西变动的话就要改名字了，否则用户端不会主动刷新，在yahoo工作组用的是版本号，例如yahoo_2.0.6.js
3.Gzip压缩
Gzip是现在最流行和最有效的压缩方式，她是GNU开发的，RFC1952标准化。
（Gzip是在服务器端压缩图片，css，脚本等，传送到用户端的浏览器再解压，这样可以提高传输速度，不过对服务器的压力会增大，一般选择部分元素压缩比较合适。）
4.避免重定向
重定向会减慢用户体验，它会延迟所有的东西直至到达新页面。一个最浪费的重定向经常会发生而我们的开发者又会经常忽略的就是比如 http://astrology.yahoo.com/astrology的结果是重定向到http://astrology.yahoo.com /astrology/ 在Apache里用Alias 或者mod_rewrite或者DirectorySlash解决。
从一个旧网站跳转到新网站也是经常要用到重定向，还有就是连接一个网站中的不同部分和在某些情况下（比如不同浏览器，不同的用户帐号类型，等等）的用户导 向。用重定向很简单，而且只需要一点额外的代码，虽然在这些情况下用重定向减少了开发者的复杂度，但它降低了用户的体验，变通的做法是用Alias和 mod_rewrite如果两个部分是在同一主机上的话，如果是由域名变更引起的重定向，变通的做法是通过Alias或mod_rewrite创建一个 CNAME（一个DNS记录，创建一个别名，从一个域名指向另一个域名）
5.配置ETags
ETags（Entity tags）是服务器和浏览器的一个功能，它用来判断浏览器缓存里的元素是否和原来服务器上的一致。ETags比last-modified date更具有弹性，它用一个独一无二的字符串来标识一个元素的版本。
源服务器用响应头里的ETag来特定一个元素的ETag：
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: “10c24bc-4ab-457e1c1f”
Content-Length: 12195
之后，如果浏览器要验证这个元素，它就会用If-None-Match头来回传ETag到源服务器。如果符合的话，一个304状态的代码就会从源服务器返回到浏览器，这样源服务器就节省了传输具体数据的开销。
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: “10c24bc-4ab-457e1c1f”
HTTP/1.1 304 Not Modified
用Etags的问题就在于它会标识那个特定的服务器，如果换了服务器，Etags也就失去了原有的功能，但是这种现在在网络上太常见了，因为我们经常用服务器集群。默认情况下，Apache和IIS会在Etag中内嵌数据，这样会动态减少验证成功的机会。
Apache1.3和2.x的ETag格式是inode-size-timestamp。虽然一个文件可能在不同服务器的同一个目录，同样的大小，安全级，时间戳等等，它的inode会随着服务器的不同而不同。
IIS5.0和6.0有同样类似Etags的东西，叫时间戳：ChangeNumber（更改号），更改号是一个用来追踪IIS配置变化的计数器，ChangeNumber在不同IIS服务器之间是不一样的。
它最终的问题就是，IIS和Apache产生的Etags会在不同服务器之间无法匹配，这样我们的浏览器就无法得到我们期待的304响应，而给我们 的是一个普通的200响应，和正常的数据流。如果你的网站只有一个服务器还无所谓，如果是集群，而你用的是默认的ETag配置，你的用户就会获得更慢的页 面，你的服务器也会有更高的负载，消耗更大的带宽资源，代理也无法高效缓存你的内容，甚至即使你有一个长时间过期的头部（按：见第三条规则），也不会阻止 它重新载入内容。
如果你不想发挥Etags提供的这个弹性验证模型的优势，你最好关掉它。Apache中关掉它的方法是在Apache的配置文件中写这么一句：
FileETag none
二、我们从代码方面来探讨有如下方法
1.减少http请求数
图片，css，script，flash，等等这些都会增加http请求数，减少这些元素的数量能减少响应时间。
CSS Sprites技术能减少图片的请求数，把零散的小图片放到一起，运用background-position来改变背景图片的位置，前提是html元素事先定义好宽高，其实就像一个遮罩，移动背景就会看到不同的景象。
内嵌图像 用data:URL scheme的方式把图片内容代码直接嵌入html代码中，这样会增大html代码的体积，改进的方式是把内嵌图片嵌入到css中（css被缓存），这样就会更好的减少http请求数而且不增大html的体积。
很多用户都是在空缓存的情况下进入你的网站的，这样第一次的速度就会显得很重要。
第一条规则是最重要的一条规则。
2.把样式表放到顶部
我们发现把css放到文档头部会让网页加载得更快。因为这样可以让页面逐渐加载。
把样式表放到接近底部的问题是它阻止了页面元素的逐渐显示。这样还会导致“flash of unstyled content” 即在样式表加载之前页面内容是以没有样式的形式显示出来的，待加载完样式后，页面重绘，内容一闪即改变了样式表现。
3.把脚本放到底部
把脚本放到尽可能底部的地方，一个原因是让页面逐渐渲染，另一个是实现更好的并行下载。
对于脚本，脚本以下的内容被阻止逐渐加载了，因为只有当下载完脚本以后才会下载下面的内容，第二个脚本引起的问题是阻止平行下载。 “http/1.1 specification”建议浏览器对一个域名， 同一时间下载数不超过2个（按：实际监测发现一般有超过2个），我曾经让ie并行下载100个图片。 当脚本正在下载的时候，浏览器不会开始下载任何东西。
4.避免css expressions
css expressions 是一个有力（和危险）的方式动态的改变css的属性。他们自ie5就开始被支持，举个例子，用css expression可以让背景色每个小时轮换一次。但是被非ie浏览器忽略的。
background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ );
expressions的问题就在与它的计算频率绝对超出我们的想象，甚至当我们移动鼠标，都会引起页面的重绘！
下面是举例页面
减少css expressions计算次数的一个方法就是使用一次性的expressions。 当第一次expression计算出一个明确的值，就让样式等于这个值，不再变动。如果样式的属性一定要动态的改变，就用时间句柄吧！
5.让脚本和样式外延
Javascript和CSS应该是外部调用还是内嵌呢？
用外部调用文件的方式更快，因为他们是可以被缓存的，如果是内嵌在页面中他们就无法被缓存了！想想如果用户要在你的网站看很多很多的页面，如果都是使用同一个外部脚本和样式，那么他们一旦被缓存，就再也不需要下载了，这样会给你带来很大的潜在好处。
6.减小脚本体积
有两个比较流行的工具是用来减小脚本的体积的–JSMin和YUI Compressor。（按：这个压缩和Gzip压缩是不一样的，Gzip是传输压缩，这个是代码压缩）。
我们以上方法，读者应该适当的选择或配合使用，我们在选择方法的原则是应该以最低的代价来完成客户端的功能。
No related posts.
博文
