設置瀏覽器緩存有下面幾種方法
Last-Modified：服務器上文件的最後修改時間
Etag：文件標識
Expires：本地緩存目錄中，文件過期的時間（由服務器指定具體的時間）
Cache-control：本地緩存目錄中，文件過期的時間（由服務器指定過期的間隔時間，由於瀏覽器根據間隔生成具體的時間）
爲了提高性能，Yslow中也提到幾條關於緩存的規則。
- 添加Expires或Cache-Control到報文頭中。
- 配置ETags
- 讓ajax可緩存
如何讓瀏覽器緩存我們的靜態資源，這也是一個需要由服務器和瀏覽器共同協作完成的事情。post、delete、put這類帶行爲性的請求操作一般不做任何緩存，大多數緩存只應用在get請求中。
簡單來講，本地沒有文件時，瀏覽器必然會請求服務器端的內容，並將這部分內容放置在本地的某個緩存目錄中。在第二次請求時，它將對本地文件進行檢查，如果不能確定這份本地文件是否可以直接使用，它將會發起一次條件請求。所謂條件請求，就是在普通的GET請求報文中，附帶if-modified-since字段，如下所示：
if-modified-since：Sun,03 Feb 2013 06:01:12 GMT它將詢問服務器端是否有更新的版本，本地文件的最後修改時間。如果服務器端沒有新的版本，只需響應一個304狀態碼，客戶端就是用本地版本。如果客戶端有新的版本，就將新的內容發送給客戶端，客戶端放棄本地版本。
這裏的條件請求採用時間戳的方式實現，但是時間戳有一定的缺陷存在。
- 文件的時間戳改動但內容並不一定改動。
- 時間戳只能精確到秒級別，更新頻繁的內容將無法生效
爲此HTTP1.1中引入了ETag來解決這個問題。ETag由服務器端生成，服務器端可以決定它的生成規則。
與if-modified-since/last-modified不同的是，ETag的請求和響應是if-none-match/ETag.
儘管條件請求可以在文件內容沒有修改的情況下節省帶寬，但是它依然會發起一個HTTP請求，使得客戶端依然會花一定時間來等待響應。可見最好的方案就是連條件請求都不用發起。那麼如何讓瀏覽器知曉是否能直接使用本地版本呢？答案就是服務器端在響應內容時，讓瀏覽器明確地將內容緩存起來。即在響應裏設置Expires或Cache-Control頭，瀏覽器將根據該值進行緩存。
那麼這兩個值有何區別呢？(Expires和Cache-Control)
HTTP1.0時，在服務器端設置Expires可以告知瀏覽器要緩存文件內容。Expires是一個GMT格式的時間字符串，瀏覽器在接到這個過期值後，只要本地還存在這個緩存文件，
在到期時間之前它都不會再發起請求。
但是Expires的缺陷是瀏覽器和服務器之間的時間可能不一致，這可能會帶來一些問題，比如文件提前過期，或者到期後並沒有刪除。在這種情況下，Cache-Control以更豐富的形式，實現相同的功能。
Cache-Control比expires優秀的地方在於，Cache-Control能夠避免瀏覽器端和服務器端時間不同步帶來的不一致性問題，只要進行類似倒計時的方式計算過期時間即可。除此之外，cache-control的值還能設置public、private、no-cache、no-store等能夠更精細地控制緩存的選項。
由於在HTTP1.0時還不支持max-age，如今的服務器在模塊的支持下多半同時對expires和cache-control進行支持。在瀏覽器中如果兩個值同時存在，且被同時支持時，max-age會覆蓋expires。
last-modified介紹
在瀏覽器第一次請求某一個URL時，服務器端的返回狀態會是200，內容是客戶端請求的資源，同時有一個Last-Modified的屬性標記此文件在服務器端最後被修改的時間。
Last-Modified格式類似這樣：
Last-Modified : Fri , 12 May 2006 18:53:33 GMT客戶端第二次請求此URL時，根據HTTP協議的規定，瀏覽器會向服務器傳送If-Modified-Since報頭，詢問該時間之後文件是否有被修改過：
If-Modified-Since : Fri , 12 May 2006 18:53:33 GMT如果服務器端的資源沒有變化，則自動返回 HTTP 304（Not Changed.）狀態碼，內容爲空，這樣就節省了傳輸數據量。當服務器端代碼發生改變或者重啓服務器時，則重新發出資源，返回和第一次請求時類似。從而保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端能夠得到最新的資源。
例子參考：http://www.cnblogs.com/zh2000g/archive/2010/03/22/1692002.html