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分钟以后的翻页才再次请求服务器的数据。
有些情况，如果我们可以预知数据的更新频率，比如多少天才可能会有一次数据更新，甚至可以考虑使用本地存储，隔一定时间才触发一次对服务器数据的请求，这样对请求数和流量的节约就更加彻底了。当然最终什么样的缓存方法适用，归根结底还取决于产品对时效性的要求，但原则还是能节约的请求和流量，尽量节约，对于访问量超大的页面尤其如此。