頁面相關的資料存放區(緩衝及Web Storage)

頁面可用的緩衝包括: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