雅虎用戶界面博客（YUIBlog）

移動瀏覽器緩存的限制，再探

在移動瀏覽器高速緩存限制：機器人，IOS，和webOS ，我共享的結果，我試圖確定在Android瀏覽器緩存的限制，內部監督辦公室，和webOS設備。 在結束這篇文章，我寫道：

使用這些結果為出發點，但要驗證他們自己做出重大決策之前，基於的假設移動緩存的限制。 移動瀏覽器世界的變化在閃電的速度，所以這項研究將有一個很短的保質期。

事實證明，這是很好的建議：白天的文章被張貼後， 史蒂夫Souders評論說，他已運行測試使用不同的方法，是比較有代表性的一個真實的網絡工作流程，並得到不同的結果。

新方法

我原來的方法直接涉及到導航頁面隨機生成的具有一定規模的，送達text/html內容類型。 結果採用此方法是可靠的重複性（webOS的除外），但史蒂夫指出，用戶不直接導航到CSS和JavaScript文件。 我的假設，即限制直接導航到HTML資源是相同的限制外部CSS和JavaScript是不正確的，所以儘管我的測試結果是有效的，他們沒有得到廣泛適用。

在許多 IM會話過程中，一些電子郵件，和一對夫婦的電話，史蒂夫和我摸索出了新的測試方​​法。 我實現了一個版本的它上面我緩存的測試框架 ，那麼史蒂夫實施了版本能夠出版結果Browserscope 。

在新的測試中，我們加載一個 HTML頁面，指的是一個隨機生成的CSS或JavaScript組件有一定的規模。 然後，我們定位到第二個 HTML頁面加載同一個組件，並檢查它是否是從緩存加載。 要確定是否有部分是從緩存中加載，我們存儲在Cookie中的時間戳每個請求;如果時間戳更新了我們第二次加載組件，我們知道請求命中服務器，這意味著該組件沒有加載從緩存。

新結果

我們發現， 所有的移動瀏覽器我們測試有較高的高速緩存限制外部資源加載一個頁面比他們一個HTML頁面本身 。 這是極好的消息為移動 web開發。

下表說明了我們的研究結果：

需要注意的是4MB的大小，我們是最大的考驗，所有的iOS設備緩存 4MB組件。 實際緩存限制這些設備可能大於 4MB。 此外，在Palm webOS的前加了一致的結果在本次測試，而它有一些問題，在前面的測試。

這有可能是低得多的限制了我以前的測試結果顯示為 HTML組件在iOS可能表明使用一個 RAM緩存這些組件，而高得多的限制CSS / JS組件在這個測試可能表明使用磁盤高速緩存，但是這僅僅是猜測。 Android的，至少不會出現使用磁盤高速緩存在這兩種情況下，因為它的緩存生存權力週期。

新建議

根據這些新的成果，再加上我以前的測試結果，我提出以下幾點更新的一套建議：

• 使用遠未來的緩存過期頭，這將阻止瀏覽器不必發送一個條件GET請求。
• 嘗試限制HTML頁面25.6KB或更少 ，如果你希望它們被緩存，因為以前的測試表明，這種限制，實行內部監督辦公室對iPad 3.2 -是最低的HTML資源限制的設備進行測試。
• CSS和JS組件保持在1MB，當然，1MB是巨大的和你的組件應該比這更小，但也懶得分裂成獨立的組件要求的可緩存的緣故，除非它的大小接近1MB。
• 考慮使用HTML5應用程序緩存 ，如果是很重要的組件在高速緩存中堅持了很長的時間，或在電源週期。
• 做你自己的測試，我強調了重要性，這在我以前的文章，我將在這裡再次強調它。 使用這些結果為出發點，但要驗證他們自己做出重要決定之前，根據他們。

查找談話： bloglines | technorati

共享和擴展： 書籤與del.icio.us | Digg它！ | 書籤交易！