Ajax無刷新分頁，已經是一個大家比較熟悉的事物了，大概就是web前端頁面上有一個js的方法，通過Ajax去請求服務器端的分頁數據接口，拿到數據後再在頁面上創建html結構，展現給用戶，類似於下面這樣：
<script type=”text/javascript”>
function getPage(pageIndex){
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
function callback(datalist){
//todo:根據返回的datalist數據創建html結構展現給用戶。
}
</script>
其中，RemoteInterface.cgi是一個服務器端的接口。我們這裡限於篇幅，涉及的實例代碼可能都不是完整的，只為了把意思表達明白。
UI上，可能會有各種款式的分頁控件，大家也都比較熟悉，比如：
但無非都是用戶點擊控件觸發這裡的getPage(pageIndex)方法，這個getPage方法可能不是那麼簡單。
如果按照代碼片段1的寫法，我們可以想象，用戶每次點擊翻頁的時候，都會請求一次RemoteInterface.cgi，在忽略數據可能有更新的情況下，除了第一次，後面每次getPage(1) 、getPage(2)、getPage(3)等等所觸發的遠程接口請求以及在網絡上往返的數據流量，其實都是重復的、不必要的。每頁第一次請求的時候都可以把這些數據以某種形式緩存在頁面上，用戶如果有興趣回頭來看之前翻過的頁，getPage方法應該先檢查本地緩存當中是否包含該頁數據，如果有，則直接重新展現給用戶，而不是去調用遠程接口。按照這個想法，我們可以把代碼片段1修改一下，如下：
<script type=”text/javascript”>
var pageDatalist={};
function getPage(pageIndex){
if(pageDatalist[pageIndex]){ //如果本地的數據列表中包含當前請求頁碼的數據
showPage(pageDatalist[pageIndex])//直接展現當前數據
}
else
{
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
}
function callback(pageIndex,datalist){
pageDatalist[pageIndex]= datalist; //緩存數據
showPage(datalist);//展現數據
}
function showPage(datalist){
//todo:根據返回的datalist數據創建html結構展現給用戶。
}
</script>
這樣做一來節約網絡請求往返的時間，更重要的是節約寶貴的網絡流量和減輕接口服務器的負擔。在低網速環境下或者接口服務器運行壓力已經比較大的情況下，這種必要的改進更能顯現明顯的優化效果。大名鼎鼎的yahoo 34條，第一條就是盡量減少HTTP請求次數。Ajax的異步請求，毫無疑問也是在http請求的范疇內。訪問量小的web應用或許感覺沒有必要，但是想象一下，如果有一個這樣的頁面：每天訪問量1000萬次，用戶平均翻5頁，其中有一頁為重復查看。那麼這樣一個頁面，按照代碼片段1的寫法，平均每天將觸發5000萬次的數據請求，而按照代碼片段2的寫法，則平均每天至少可減少1000萬次請求。如果每次請求的數據量是20kb，則可以節約1000萬*20kb=200,000,000kb 約合190G的網絡流量。這樣看節約的資源是相當可觀的。
如果要繼續深究的話，代碼片段2當中數據緩存方法還值得討論一下。我們前面假定可以忽略分頁數據的時效性，但實際應用裡面時效性卻是個不能回避的問題。緩存毫無疑問會導致時效性的降低，真正的緩存方案應該還要依賴對應用時效性要求的分析和取捨。
對於一般不是特別強調時效性的內容，頁面上的緩存應該還是可以接受的，一來用戶不會一直停留在一個頁面上，頁面之間有跳轉造成重新加載時，可以獲得更新後的數據。另外如果用戶有刷新頁面的習慣的話，當他特別想看列表是否有數據更新的時候，可以選擇刷新頁面。如果追求完美的話，還可以考慮設定一個時間范圍，比如5分鐘。如果用戶一直停留在當前頁面超過5分鐘，那麼5分鐘內他的翻頁都是先讀取頁面上的緩存，5分鐘以後的翻頁才再次請求服務器的數據。
有些情況，如果我們可以預知數據的更新頻率，比如多少天才可能會有一次數據更新，甚至可以考慮使用本地存儲，隔一定時間才觸發一次對服務器數據的請求，這樣對請求數和流量的節約就更加徹底了。當然最終什麼樣的緩存方法適用，歸根結底還取決於產品對時效性的要求，但原則還是能節約的請求和流量，盡量節約，對於訪問量超大的頁面尤其如此。
對於時效性要求高的一類數據，緩存就完全不適用麼?當然不是的，只不過整體的思路還得再變一變。一般所謂變化，可能主要是列表當中的數據有增、減或者改動，但是絕大多數的數據還是保持不變的。大多數情況下，前面講的設定在一段時間范圍內做緩存還是適用的。
如果有接近於要求實時更新數據的需求，大家可能很容易想到使用定時器的方法，比如每20秒執行一次getPage(pageIndex)方法並重繪列表。但大家只要聯想到前面1000萬次頁面訪問的假設，就會發現這無疑是一件超級恐怖的事情，按照這種訪問量和重試的頻率，服務器壓力山大呀。關於這種情況怎麼處理，我想請大家去看一看Gmail、163郵箱和新浪郵箱等對郵件列表頁的處理方式。它們幾乎同時滿足了我們之前的假設：超級大的日訪問量，對數據要求實時更新等。用網絡抓包工具分析一下不難發現，它們在用戶重復請求同一個頁碼的數據時，都不會向服務器發出請求。為了保證有消息更新時能夠及時通知用戶並且更新郵件列表，可以使用一個定時、重復進行的異步請求，但是這個請求只是做一個狀態查詢，而不是刷新列表。只有獲取到有消息更新的狀態時才會發起請求去獲取更新的數據，或者狀態查詢的接口在發現有更新時會直接把更新的數據返回。事實上，163郵箱這個定時的狀態查詢，間隔時間都是設的比較長的，大概兩分鐘一次，新浪郵箱這個時間間隔更長一些，大概5分鐘一次，可以了解它們都在盡力減少請求數量。但是這種處理方式，可能就不是僅前端單方面就能做的，實現方案需要和後台接口整體考慮才行。
現在我們再回過頭來看一下代碼片段2當中的數據緩存方法。現在不再討論請求數量和流量的節約，我們來看一下前端的實現上還有沒有什麼值得深究一下的。按照代碼片段2示意的處理方式，原始數據被儲存起來，當再次被調用時，showPage(datalist)需要再次根據數據去重建html結構展現給用戶，但是之前這個創建結構的過程我們是有做過的，是不是可以考慮在第一次創建結構的時候，直接把這個結構存起來呢?這樣可以減少js重復的計算，特別當結構比較復雜時更值得考慮。再想一下，這個結構之前在頁面上創建過了，翻頁的時候銷毀並再次創建新的結構，也是耗費資源的，能不能第一次創建好了之後，翻頁的時候不銷毀，只是通過控制CSS樣式給它隱藏起來，重復翻頁的時候也只是在這些創建好的結構之間控制彼此顯示或者隱藏?
最後，這裡討論的方法，不一定適用所有情景，但或者會有些許啟發，可以在適當的時候嘗試其中一二。同時思想如果發散開來，或者還不僅僅可以運用在無刷新分頁。這裡拋磚引玉，大家一起探討。