[转]网站优化-IIS7下静态文件的优化

本文转自：http://www.cnblogs.com/Leung/archive/2009/10/26/1590256.html

在网站开发过程当中,一般咱们会对网站的静态文件作处事,像图片文件,CSS,JS文件,其实之前也写过相似的文章,如今只是作一个针对性的总结下.

JS文件处理:

网站优化来讲,实际上是见议咱们放在网页最后来来加载,由于JS文件它是一个阻塞模式,当一个线程在下载JS文件时须要等它下载完才能接着加载下面的内容,那么若是把JS放在网页的头部这样会有一个阻塞下载,若是网速慢的话,下面的网页内容显示不出来,这样的用户体验是很很差的,有可能有的用户会认为网站打不开呢?但有时由于UI上的处理,特别是网站功能菜单这块的处理又不得不放在网站前面.那这样怎么办?

解决方法:

一、对JS文件压缩，网上有大把压缩工做，把JS文件里面的空格去掉，把那么没必要要的注析去掉，把JS写成一行，经过减少JS文件的大小，减小网络的传输流量，达到节省传输时间。

二、启用服务器端的静态文件压缩，就是在REQEUST响应前先对JS文件进行一次压缩，当前会增长点CPU的运算，不过这个能够经过下面的办法来解决，减小CPU压缩的次数来达到

提高CPU的可能率。IIS7的操做以下,启动静态压缩就能够了.

三、针对上面的优化咱们还不够，首先每次用户访问同一个用户都会去加载一样的JS文件，咱们须要充份利用用户的浏览器来减小对同一文件的请求，经过减小文件的请求能够减小CPU对文件压缩的运算次数。咱们只须要给静态文件加上过时时间就能够了，固然也须要加上ETAG，光一个过时时间是不足以彻底解决过时的问题，什么ETAG的做用能够参考

{

服务器端对静态文件返回： Cache-Control的header 跟 etag / last-modified的header 是两种彻底不一样的Cache方式。
前者是告诉浏览器说，你缓存住这个资源若干时间，在这段时间内，若是有别的页面再调用这个资源，你就直接使用你此次保存下来的版本，彻底不须要再跟服务器拿，任何http请求的都不须要发送给服务器。
后者是告诉浏览器说，你能够永久的缓存住这个资源以及相应的hash（也就是etag）或者说资源的最后更改时间。可是！之后若是有别的页面也调用了这个资源，你仍旧须要把我上次返回给你的hash或者最后修改时间经过一个新的请求发送过来。服务器端会验证一下hash / 最后修改时间跟服务器上面的如今最新的版本是否还一致，若是一直就返回304，而不返回实际内容，告诉浏览器说你可使用以前缓存的内容。若是不一致，就返回新版本的内容。
两种方式的区别在于一个有时间限制，一个没有；一个在符合缓存条件的状况下不发送任何新的http请求，一个则每次都须要发送新的http请求去验证缓存是否过时。
从你介绍的内容看，你应该是在推荐使用第一种缓存方式。只有Cache-Control header的话，服务器不管如何是不可能返回304的。
由于浏览器传统上对一个服务器限制最多只会有两个并发请求，Cache-Control header的缓存效果比使用etag会好不少不少。一个无内容的http请求也是有可能产生阻塞。
而你举例的Cache-Control max-age仅有10分钟，这彷佛实际效果并不明显。即使是浏览器缓存了资源，它10分种后，或者说用户次日再次浏览的时候，全部的静态资源又得再从新下载一遍。
对于静态资源，我通常是放一个几年的max-age，只要客户端的缓存空间足够大，网站的全部静态资源都只会被请求一次。
etag / last-modified的header IIS对于静态文件其实默认就会自动添加的，无须任何设置。我却是在尝试将其使用在动态页面中。动态页面在输出以前，先根据本身的Response buffer中的字符串内容计算一个md5，而后做为etag插入到Response header中。下次客户端访问同一页面的时候，便会把以前收到的etag发送回来。页面在flush response以前先检查一下客户端发送过来的etag与这个生成的Response text md5是否一致，若是一致，就不返回完整的Response内容，而直接丢一个304回去。页面生成的时间不会减小，可是在页面内容不变的状况下（用户刷本身首页看有无更新）传输时间会大幅减小。可是，这也意味着页面中的全部时间都不能使用过去形式去显示。不然，用户每次刷页面，页面的内容都会由于这些时间显示而使得md5结果不一样。 }

IIS7 具体的操做以下：

选择HTTP响应头>设置经常使用标头项

说明:保持HTTP链接选项是说明,当一个用户请求这个文件后不会断开HTTP的连接,时间是300,至关于它会在http 头加一个keep-alive这个是针对于HTTP 1.1协议的一个功能

内容过时的话要看你的实际业务需求了,通常那些改动比较小的能够把过时时间放长些.

图片文件的处理:

  对于网站应用程序咱们知道应尽可能的减小HTTP REQUEST次数和一次性加载文件的过大.然而这二方面又好像是有些矛盾,文件要减少它的大小那么只好把一个大图切成多个小图下载了.

可是这样又会把增长HTTP的请求次数.怎么办呢?

对于有些背景图咱们能够用CSS来处理,只加载一个图片,但能够用CSS定位在不一样的地方.还有方法就是如同上面JS的处理,给图片加上过时时间.任外一种办法就是分配独立的APPLICATION专门处理图片的请求与主站分开.

流媒体文件处理:

  针对flash文件其实也是同样,由于它第一次加载时会存放在客户端,要充分利用上客户端的CACHE.像FLASH播放器这样的静态文件能够把过时时间设很长.采用专门的站点来播放.至关于在服务器端提供多进程组件服务于用户的请求.

针对动态内容的优化能够参考

http://www.cnblogs.com/Leung/archive/2009/10/26/1590091.html