[轉]網站優化-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