页面可用的缓存包括:Http Cache, Local Storage, Session Storage以及Application Cache. 它们都可以用来减少请求数量，以提高页面的性能及减少流量消耗，这对于移动端的浏览器来说更为重要 (另外还有Memory Cache, 不过对于前端工程而言是透明的)。
Http Cache
最为常用的缓存机制。相对后三项属于浏览器内核内的模块(也是H5中定义的标准)，Http Cache早已存在于HTTP模块中了。它是网络层对HTTP协议实现中一部分。它基于对响应头中的Cache Conrol信息进行解析，执行新鲜度检查、条件更新等操作来管理缓存。缓存的容量限制及淘汰、更新算法在各个浏览器中实现都不相同，属于浏览器及页面开发优化的一个重点。比如缓存赵多的内容会使得网页请求的数量更少，但是缓存的内容达到一定量后，会导致查询及I/O变慢，反而使得投入产出比下降。容量是基于存储空间而定，不同的浏览器会有不同的最大值，而且不同的用户在实际使用是对缓存总量的依赖也不同。这些都是浏览器性能优化时考虑的内容。
详细内容可以通过<<管好页面缓存>>了解。
它的一个问题在于缓存内容的淘汰基于算法的实现，无法保证单独针对需要保留某个资源。所有的资源都可能因为缓存策略的变化，存储空间的变化而遭到淘汰。所以针对这种场景，HTML5定义了能更好地支持离线浏览的Applcation Cache。
Application Cache
应用于离线场景下可以让用户继续使用页面的场景，比如支持离线的游戏、及Office编辑应用等。 没有明确的容量限制，WebKit系列的浏览器会有每个域名5MBytes的限制(默认而已，具体会有变化)。考虑到一些浏览器存储时使用UTF-16编码，并不能真正达5MBytes。
Application Cache是一种基于请求的主动缓存，缓存的内容受Cache Control信息控制，包括相关的新鲜度检测等。
实际应用时, Application Cache比较容易出问题, 典型的有，如何更改manifest文件以达到资源更新的目的，以及可能会造成重复缓存(manifest解析的时机不同)。 在决定使用Application Cache，一定要好好读读这篇文章:<<Application Cache is a Douchebag>>。
Application Cache提供的API非常简单，它并不依赖于JS就可以实现缓存的目的，同是又可以通过API来获得缓存的状态。详细内容参考H5规范中的定义<<Offline Web Applications>>。
Local Storage & Session Storage
使用方式和Cookie相似，主要应对Cookie不适合存储较大数据的情况，否则会导致与服务器交互的数据变大，性能易受到影响。。相对于Applcation Cache, 它们的使用依赖于JS, 但是简单明确。
Local Storage及Session Storage在H5称为Web Storage, 使用相同的API, 只是两者存在周期不同。前者可以一直存储，没有时间限制。后者则只存在于一个会话期，用户关闭浏览器后就会清除（除非浏览器支持重启后恢复上次的会话）。
在存储的API中，有不同的调用方式, 其性能是有差异的，并且不同的浏览器表现迥异：
可能的原因是相对大家都关注的JS Engine执行性能问题的逐步改善，DOM的操作时间对性能的影响更大。下面的数据来自IE团队针对使用较多AJAX请求的页面的统计:
Web Storage的最大问题在于存储的同步问题，好在有一些JS库可以帮助改善这个问题。详细的内容可以阅读<<HTML5 and JavaScript Web Apps>>第6章Optimizing with Web Storage.
转载请注明出处: http://blog.csdn.net/horkychen
