動(dòng)態(tài)頁(yè)面的瀏覽器緩存
我們知道,對(duì)于WEB頁(yè)面中的JS和CCS,并不會(huì)每次都請(qǐng)求完整的內(nèi)容,有時(shí)候會(huì)直接利用本地的緩存;而對(duì)頁(yè)面本身,卻往往會(huì)去加載完整內(nèi)容,對(duì)于服務(wù)器來說可能每次也要生成完整的內(nèi)容,并送到客戶端;同樣的,對(duì)于一些http接口,每次調(diào)用也會(huì)去重新生成數(shù)據(jù),瀏覽器也會(huì)重新加載完整的數(shù)據(jù);
但有這樣一些頁(yè)面,雖然是動(dòng)態(tài)的但變動(dòng)頻率較小,且對(duì)于同一用戶重復(fù)調(diào)用可能很多(比如說個(gè)人管理后臺(tái)或者新聞首頁(yè)面),我們希望像js或者ccs那樣在客戶端緩存起來.并且,在我們希望的時(shí)候,可以更新客戶端備份的那個(gè)頁(yè)面,或者接口數(shù)據(jù).是否可以做到呢;
事實(shí)上,瀏覽器可以緩存js,就一定能緩存我們的動(dòng)態(tài)頁(yè)面;
先研究下js是如何緩存起來的:
用firebug看一下js的加載:
先強(qiáng)刷(ctrl+F5)一下 http://ilab.iteye.com/ 頁(yè)面,觀看js的加載如圖
狀態(tài)為200 , 查一下200的含意 :
請(qǐng)求成功(其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。)
這是對(duì)js文件的完整加載;
再直接F5刷新下 http://ilab.iteye.com/ ,觀看js的加載如圖
狀態(tài)為304,再查一下304的含意:
未按預(yù)期修改文檔。客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。服務(wù)器告訴客戶，原來緩沖的文檔還可以繼續(xù)使用。
此時(shí)其實(shí)并沒有從服務(wù)端加載完整文件而是去讀的本地緩存;
從304的描述來看,我們知道,請(qǐng)求依然發(fā)出,并由服務(wù)端告知瀏覽器,掉用緩存;
我們可以總結(jié)出兩點(diǎn):
1.
由于服務(wù)端只是返回簡(jiǎn)單的頭信息,并沒有生成完整頁(yè)面,所以雖然請(qǐng)求依然發(fā)出,對(duì)于瀏覽器和服務(wù)器來說都更快更輕松了;
2.
我們可以控制瀏覽器去更新緩存;)
具此,我們可以得出結(jié)論,對(duì)于某此動(dòng)態(tài)頁(yè)面來說,完全可以充分利用瀏覽器緩存來降低服務(wù)器壓力,提升客戶端速度;
----------------------------------分隔線 ----------------------------------------
現(xiàn)在我們來看下要怎么做;
由于對(duì)文檔的描述在http頭信息中,并且依據(jù)304的描述,我們知道,這個(gè)屬性和 Modified Time有關(guān),我們比對(duì)下普通的頁(yè)面和js的頁(yè)面的respose的頭信息的不同:
我們發(fā)現(xiàn),多了個(gè)Last-Modified的屬性;
再比對(duì)請(qǐng)求,
發(fā)現(xiàn),多了If-Modified-Since;
武斷的推測(cè)一下(或者認(rèn)真的讀下http協(xié)議的文檔):我們可以這樣認(rèn)為:
1.第一次請(qǐng)求成功返回202;
2.假如返回頭信息有Last-Modified屬性 則存入瀏覽器緩存;
3.再次請(qǐng)求,假如請(qǐng)求的為緩存頁(yè)面,則頭信息中加入 If-Modified-Since;
4.服務(wù)端通過If-Modified-Since(即上次響應(yīng)中Last-Modified的值)來判斷是否需要更新,否的話返回304;
5.假如返回304,則瀏覽器則讀緩存;
按照這個(gè)原理我們通過 HttpServletResponse, HttpServletRequest來償試實(shí)現(xiàn)下:
對(duì)任意一個(gè)頁(yè)面先來句
Java代碼
- getResponse().addHeader("Last-Modified", "hello kitty");
然后再次請(qǐng)求該頁(yè)面時(shí),我們就可以發(fā)現(xiàn)請(qǐng)求中就有了 If-Modified-Since 屬性
Java代碼
- getRequest().getHeader("if-modified-since");
通過這句代碼,拿到具體值;
假如判斷為不用更新則直接返回304
Java代碼
- getResponse().setStatus(HttpServletResponse.SC_NOT_MODIFIED);
并且立即結(jié)束返回,不用繼續(xù)執(zhí)行;
對(duì)于取到的if-modified-since,即是上次存入的Last-Modified,里面的值到是可以很隨意,你除了放時(shí)間,也可以放memberId;
--------------------------------分隔線 ----------------------------------
實(shí)現(xiàn)問題也解決了;
最后一個(gè)問題,是怎么保證接口,或者頁(yè)面的動(dòng)態(tài)性;也就是說怎么通過Last-Modified或者if-modified-since來判斷頁(yè)面不需要更新;
考慮最簡(jiǎn)單的情況,這個(gè)接口或者頁(yè)面僅提供和用戶相關(guān)的不同信息,并且該信息一但建立則不會(huì)改變;
那對(duì)于此接口,假如參數(shù)中包含memberId屬性,則一但具有if-modified-since值,則永遠(yuǎn)返回304;因?yàn)閷?duì)于不同url,瀏覽器均會(huì)進(jìn)行緩存;
假如memberId屬性在cookie中,url一致,那么,在Last-Modified中存入memberId,判斷時(shí)于cookie或者session中url比對(duì),相同則認(rèn)為是正確的緩存返回304;
現(xiàn)在,新的問題來了,用戶的相關(guān)信息更新了;
假如這個(gè)更新頻率不是那么頻繁,那么想辦法做個(gè)更新機(jī)制還是合理的;你需要一個(gè)地方在服務(wù)端記錄用戶接口信息的版本號(hào)了,從if-modified-since中取得上次的版本號(hào),然后進(jìn)行比對(duì),如果相同,則返回304;
在某些情況下,獲取更新記錄信息要比計(jì)算合成完整信息并利用帶寬將數(shù)據(jù)傳給客戶端代價(jià)小得多,此時(shí)你可以試下WEB服務(wù)動(dòng)態(tài)接口的靜態(tài)緩存;
【編輯推薦】
