http://blogold.chinaunix.net/u1/45336/article_134715.html
网站的性能(Performance)要考虑两方面，一方面是在Server端的运行效率，另一方面是在Client端感受到的效率。不要以为Server端效率高这个网站或者服务给用户的体验就是高效的，如果不考虑影响Client Performance的因素，Server端跑得再快用户也可能感觉慢得和牛一样。
Yahoo的哥们做的研究真不是盖的，他们还写了本书《High Performance Web Sites》详细介绍如果提高Client Performance。公司内部也有一个Team做这方面的事情，听过他们的培训，和Yahoo说的差不多，所谓英雄所见略同。
给静态资源(HTML文件，图片文件等）的Repsone加上Expires/Cache-Control Header是很有效的一招。如果HTTP Response中有Expires这样的Header的话，浏览器会Cache这个资源，理想状况下（注意，只是理想状况），在Expire Date之前，不会再发HTTP请求给Server要这个资源，不过Expires的值只能是一个固定日期，比如“Thu 27 Nov 2008 07:00:00 GMT”，不能是一个类似“从现在开始之后10年”这样一个随机浮动的值，如果要这样的效果，可以用Cache-Control这样的Header，如果HTTP Resposne中有这样的Header:“Cache-Control: max-age = 100”，表示这个资源在cache中的最大寿命是100秒。一般说来这种静态文件永远不应该过期，如果真的要给这个Cache加上一个期限，那我希望是――一万年，“Cache-Control: max-age = 315360000000”;
其实就应该给Expires设一个永远不会过期的时间，比如你现在有一个文件叫logo.gif，需要用一个新的logo的时候，你不要去覆盖原来的文件，而把新的logo存成logo_v2.gif，让相关网页引用新的logo_v2.gif，这样可以让新老网页同时工作，实在犯不上为了节省存储空间覆盖原有文件。
对Apache服务器，使用mod_expires，在httpd.conf或者.htaccess中加上
<FilesMatch "\\.(ico|gif|jpg|html)$">
ExpiresDefault "access plus 10 years"
</FileMatch>
还有，同一个HTTP Response中可以同时有Expires和Cache-Control，但是Cache-Control权限比Expires大，会override它的。
HTTP的Response中还会有另外一个Header叫Last-Modified，比如“Last-Modified: Thu, 06 Apr 2006 21:17:12 GMT”，浏览器访问一个URI得到这样的Resposne之后，就知道这个资源最后一次的修改时间，下次需要再次获得这个资源的时候，会发一个Request给Server，不过这个Request中有一条“If-Unmodified-Since: Thu, 06 Apr 2006 21:17:12 GMT”，如果在Server端在这个日期之后对这个资源进行了修改，就会照常返回这个资源给Client端，但是如果没有修改，就会返回一个304 (Not Modified) Response而不返回资源，告诉Client端：“这个资源从上次给你之来从来没改过，你放心用你Cache中的好了。” 一个304 Response比一个静态资源通常小多了，这样就节省了网络带宽。
让我们回过头来比较一下Expires和Last-Modified这两个东西，似乎Last-Modified比不上Expires，因为虽然它能够节省一点带宽，但是还是逃不掉发一个HTTP请求出去，而Expires却使得浏览器干脆连HTTP请求都不用发，岂不痛快！那还要Last-Modified这个物体干什么？理想状况的确是这样，不过当用户在IE或者Firefox里面按F5或者点击Refresh按钮的时候（不是在URL栏里重新输入一遍URL然后回车），就算对于有Expires的URI，一样也会发一个HTTP请求出去，所以，Last-Modified还是要用的，而且要和Expires一起用。
除了Last-Modified，HTTP Response中还可能有另外一个Header: ETag，使得Server上的静态资源有点“版本控制”的味道;假如HTTP Response中包含“ETag: "abcdefg1234:0001"”，等于告诉Client端，你拿到的这个版本的资源有个ID，叫做abcdefg1234:0001，下次需要发Request索要同一个URI的时候，在Request里面加一条“If-None-Match: "abcdefg1234:0001"”，好，Server端做了一些修改，下次这个Client再来了一个请求，但是这时候资源已经改了，所以返回这个新资源，还有新的tag “ETag: "abcdefg4567:0001"”（这个etag我是胡写的）,这样，Client端等于Cache了两份，在需要索要这个资源的时候，可以包含这样的Header: “If-None-Match: "abcdefg1234:0001" "abcdefg4567:0001"”,这样，即使Server端头脑发热，把这个资源Roll back回原来的版本，依然会返回304 (Not Modified) Response，因为它知道Client端Cache着以前的版本呢，这点功能是Last-Modifed/If-Not-Modified没法做到的。
不过ETag/If-None-Match这点功能实在是个鸡肋，首先，Server端的资源不大可能Roll Back，更重要的是，有可能造成Client Performance下降。对于只有一个Server的网站，没什么问题，但是现在稍微上点规模的网站都需要Scale Out，也就是说需要前端一个Load Balancer，后面接多台Server来处理请求，俗称Cluster，既然是Cluster，那么每个请求到底返回什么结果应该和分配到哪个Server无关，不过这个ETag可能就坏事了。假如用户的第一次请求分配给Server A，返回“ETag: "abcdefg1234:0001"”，但是第二次请求分配给了Server B，Server B上这个资源和Server A上的一模一样，但是计算出这个资源的ETag是"abcdefg1234:0002"，这下麻烦了，虽然内容一样，但是ETag不匹配，还是浪费了带宽把资源发送了一遍，冤枉啊！而事实上，不同Server上的ETag很有可能不同，对于Apache，ETag的计算考虑了inode，对于IIS,ETag考虑了metabase的修改版本，要保证不同server上的这些信息一致，有点小难。不过不是有Last-Modified/If-Not-Modified吗？Server端看到If-Modified-Since，对照一下时间对得上，不管If-None-Match，可以直接发回304(Not Modified)呀，很不幸，RFC2616对这种情况做了规定，如果既有If-None-Match又有If-Modified-Since，除非两者不冲突，不然不会返回304。
所以说ETag就是一个害人精，按照Yahoo的建议，别费劲想办法同步不同Server上的ETag了，干脆就把ETag删除得了（缺省，Apache和IIS都是有ETag的)，我Sniff了一下Yahoo的若干网页返回HTTP Response，的确没有ETag，人家的确是知行合一;
对于Apache，在httpd.conf或者.htaccess中加一行就搞定了:
FileETag none
对于IIS 6，可就有点费劲了，首先，似乎没有办法通过Config来把ETag去掉，查了很多资料，问了很多人，似乎能够去掉ETag的办法只有写一个ISAPI Filter来弄，Sniff了一下Microsoft的几个网页的结果显示ETag都稳当当的存在，估计目前真的没有什么好方法。
只好退而取其次，保证不同Server上的ETag一致了。 IIS对Etag的计算算法是ETag = {Filetimestamp:ChangeNumber}, Filetimestamp保持一致没什么问题，ChangeNumber是metabase的change number，就有点难保证Cluster中每个Server都一样了，所以，干脆就把它设成固定值好了，这个连接告诉我们该怎么办，很可惜，没有找到彻底删除ETags的配置。