移動瀏覽器緩存限制：機器人，IOS，和webOS
6月28日，2010在8:45上午由Ryan樹叢| 發展 ， 性能 | 19評論更新（2010年7月12日）：雖然在這篇文章中所描述的結果是準確的HTML頁面，新的測試顯示非常不同的CSS和JS資源的緩存限制。 描述了在移動瀏覽器緩存限制，再更新的結果。
韋恩Shea和Tenni陶依爾在2008年年初，寫上一個YUI博客文章的iPhone可緩存中，他們到的各種特性和限制在iPhone OS 1.x的移動Safari瀏覽器的緩存共享研究成果 除其他事項外，他們發現，超過25KB更大的各個組成部分是不緩存，有475KB和500KB之間最大的總緩存大小。
自那時以來發生了很大變化。 我們已經看到了兩個新的主要版本和次要版本的iPhone操作系統（IOS），和其他幾個與精幹瀏覽器的移動設備很多都出現挑戰iPhone的。 斯托揚STEFANOV發現，在2009年年底， iPhone的緩存限制，改變了 （可悲的是，壞）。 但是，在做的事情站在現在？ 而那些非的iOS瀏覽器？
背景
瀏覽器有兩種類型的緩存，我們正在關注這些測試的目的：
- 組件緩存 ，對象緩存，存儲個人文件。 所有的HTML，CSS，JavaScript的，和圖像進入組件緩存。 每當它需要這些組件之一，瀏覽器首先檢查網絡請求之前緩存。
- 又稱後退/前進緩存， 頁面緩存 ，存儲整個頁面及其所有組件，以及它們當前的狀態。 當您使用的向前或向後“按鈕，瀏覽器將加載頁面，如果可能的話從頁面緩存。
HTML5的應用程序緩存是另一種類型的緩存，這是通過移動瀏覽器的廣泛支持。 瀏覽器廠商已經做了記錄的應用程序緩存的限制，良好的工作，所以我不包括在我的測試。 稍後更多的應用程序緩存。
設備進行測試
我測試以下的手機瀏覽器/平台組合：
- 的Android 2.1（Nexus One的）
- 移動Safari瀏覽器（第一代的iPhone）的iOS 3.1.3
- 在iOS 3.2移動Safari（IPAD）
- 在iOS 4.0（iPhone 3GS的移動Safari）
- 在iOS 4.0移動Safari（iPhone 4的）
- webOS的1.4.1（PALM PRE PLUS）
注：隨著移動Safari除了在iOS 4.0，我在每個類別中只有一台設備測試。 如果有變化以外的操作系統上安裝軟件的設備或個人之間的差異，我的測試中不會檢測到這些變化。 這些特殊的設備進行了測試，因為他們是我訪問的，並不是因為我認為他們比其他設備更重要。
方法論
緩存測試是乏味的，但相對簡單。
我寫了一個微小的Sinatra的應用程序（ GitHub上餐桌吧！ ），生成一個響應組成的一個偽隨機字母和空格字節的請求數量。 gzip壓縮或解壓縮的反應可以送達。 以下的遠未來過期響應頭發送，以確保所有的反應都認為可緩衝的：
的Cache-Control：max-age的= 315360000 到期日：星期五到2020年5月01日3時47分24秒GMT
在我的本地網絡，然後我手動執行以下步驟，以每台設備上測試組件緩存：
- 加載緩存測試索引頁。
- 點擊一個鏈接到一個特定大小的組成部分，從5KB到20MB，並等待它完成加載。
- 點擊“後退”按鈕。
- 再次點擊同一鏈接。 觀察的隨機字符是否是相同的，以及是否在服務器控制台打印請求的日誌條目，以確定組件是否是緩存在第2步。
- 重複和調整組件所需的大小來確定最大的組成部分，這將是緩存的大小。
要測試的頁面緩存，我的表現基本上是相同的步驟，而不是攻鏈接再次在第4步，我拍了拍瀏覽器的前進按鈕，使其使用頁面緩存，而不是組件緩存除外。
通過調整服務器發送適當ETag Last-Modified ETag或Last-Modified響應頭（單獨測試）和省略遠未來過期頭，支持ETag和Last-Modified決心。 然後我檢查服務器收到請求驗證，瀏覽器發送的預期頭If-None-Match If-Modified-Since步驟4頭。
結果
我測試用gzip啟用和禁用，但我發現，Gzip已沒有任何設備上的效果可緩存 。 解壓縮組件的大小是在所有情況下，重要的，不論是否該組件提供gzip壓縮。 正因為如此，這裡提到的所有組件的大小是未壓縮的大小。
下表說明了我的整體結果。
| 瀏覽器/操作系統/設備 | 單組分極限 | 組件總限額 | 頁面緩存的大小限制 | 支持的Last-Modified | 支持的ETag | 生存動力循環 |
|---|---|---|---|---|---|---|
| 的Android 2.1（Nexus One的） | 〜2MB（2,048,000） | 〜2MB（2,048,000） | ∞2 | 是 | 是 | 是 |
| 移動Safari 3.1.3的iOS（第一代的iPhone） | 0B 1 | 0B 1 | ∞2 | 沒有 | 沒有 | 沒有 |
| 移動Safari 3.2，IOS（IPAD） | 25.6KB（26214 b） | 〜281.6KB（288354） | 25.6KB（26214 b） | 是 | 是 | 沒有 |
| 移動Safari 4.0，IOS（iPhone 3GS的） | 51.199KB（52428 b） | 〜1.05MB（1100988） | ∞2 | 是 | 是 | 沒有 |
| 移動Safari 4.0，IOS（iPhone 4的） | 102.399KB（104857 b） | 〜1.9MB（1992283） | ∞2 | 是 | 是 | 沒有 |
| webOS的1.4.1（PALM PRE PLUS）3 | 〜1MB（1,048,576） | ？ | 〜1MB（1,048,576） | 沒有 | 沒有 | 是 |
註釋：
1移動Safari瀏覽器上的iOS 3.1.3不出現任何組件緩存，無論規模大小，除了頁面緩存。 目前還不清楚這是否是有意或錯誤。
出現在Android 2.1的iOS 3.1.3和iOS 4.0（但不是3.2的iOS）的頁面緩存是有限的，只有當它涉及到個人頁面大小可用RAM。 我沒有嘗試，以確定究竟有多少單獨的頁面，在頁面緩存共存一次。
3 webOS的測試結果不一致，並在各點的緩存似乎完全停止工作，直到手機電源循環。 我不認為這些結果定論，甚至是值得信賴的，但他們為便於比較，這裡列出。
機器人
Android瀏覽器表現出最好的緩存行為，所有測試設備。 雖然它似乎對各個組件的大小沒有限制，總緩存大小似乎被限制在大約2MB，這意味著，個別元件，有效地限制為2MB，以及。
頁面緩存出現了對單個頁面的大小沒有限制，高高興興地緩存每個字節，我把它，直到可用內存被耗盡，瀏覽器崩潰。
我驚喜地發現，Android的組件緩存存活瀏覽器重新啟動和電源週期，iOS設備的壯舉沒有能夠匹配。
可能的警告： Android的WebKit的源代碼樹的審查，使我相信，其高速緩存限制可能基於RAM和/或快閃記憶體上的特定設備上運行它提供的金額適應。 如果情況屬實，這些數字可能只適用於Nexus One的。 事實上，如果未使用的內存，而不是總內存緩存大小相適應，這些數字可能只適用於我的Nexus One。
我可能錯了，但在iOS 4.0測試結果的差異上的iPhone 3GS和iPhone 4支持這一理論。 （Android和移動Safari都是基於WebKit的瀏覽器，所以他們可能有共同的行為。）如果你熟悉WebKit源，可以更清楚地有鑑於此，請與我取得聯繫。
的iOS
跨越三個最新版本的iOS結果差異很大。 令人驚訝的是， 手機上的iOS 3.1.3的Safari沒有任何規模的緩存組件 ，儘管有明顯無限的頁面緩存的大小。 這是令人不安的，因為它意味著的iOS 3.1.3用戶可能獲得一個次優的瀏覽體驗，尤其是如果他們不使用WiFi。 無限的頁面緩存的大小這裡沒有一點好處，因為它只涉及到為前進/後退導航發揮。 這種行為是從觀察別人以前的IOS版本，我無法想像任何充分的理由，因為它顯著的變化，所以我懷疑這可能是一個錯誤。
移動在iOS 3.2的Safari（這是唯一可以在iPad上）不會出現這個錯誤。 25.6KB組件限制和〜的281.6KB總緩存限制總比沒有好，但他們仍顯得微不足道測試的其他設備相比。 獨特的iOS設備中，出現的iPad限制在頁面緩存的頁面大小25.6KB，作為其組成部分的大小限制相同。
在iOS 4.0移動Safari瀏覽器iPhone 3GS和iPhone 4上表現出不同的限制，這意味著限制適應的基礎上可用的RAM（iPhone 3GS的有256MB，而iPhone 4有512MB測試兩個設備有32GB快閃記憶體） 。 在iPhone 3GS上的iOS 4.0有51.199KB元件的大小限制了〜1.05MB總組件緩存大小。
組件的大小限制在iPhone 4上，幾乎完全是兩次在iPhone 3GS上的限制，在102.399KB。 總組件高速緩存的大小約為1.9MB。 也許是因為單獨的iOS 3.2和iOS 4.0開發，而是從一個共同的祖先分支，出現的iOS 4.0的頁面緩存大小一樣的iOS 3.1.3測試，這兩種設備的可用RAM只能由有限的。
iOS設備沒有保留跨強制瀏覽器重新啟動或設備的電源週期的緩存的內容，雖然他們沒有保留高速緩存時，只是沒有實際殺害的瀏覽器開關應用。
webOS的
我對webOS的測試結果不一致的，我對他們沒有多大信心。 我已經包括了什麼數據很少，我設法收集純粹為了完整性。 請隨身攜帶巨額糧食的鹽。
作為近，因為我是能夠確定的是，webOS的可能有大約1MB的各個組件的大小限制，與匹配的頁面在頁面緩存的大小限制。 我無法哄If-None-Match If-Modified-Since請求頭的webOS，這意味著它不支持ETag和Last-Modified 。
在某些測試中，它出現的webOS的最大元件尺寸大於1MB，但是這是不一致的。 至於我可以告訴大家，webOS的出現有一個討厭的錯誤，一定點後可能達到時的最大總緩存大小緩存完全停止工作，共直到手機電源循環。 在某些情況下甚至電源循環沒有修復的緩存破損，所以我最終放棄了試圖建立該問題的確切原因和WebOS的高速緩存的確切界限。
建議
基於這些結果，我開發測試設備的Web應用程序的人提供了以下建議：
- 使用遠未來的緩存過期頭。這將阻止發送一個條件GET請求，將提高webOS的緩存能力，它不支持瀏覽器
ETag或Last-Modified。 - 至少要等到iPad上的iOS 4.0到達，盡量限制個別組件大小為25.6KB或更少 ，解壓縮。 並敦促您的iPhone的用戶盡快升級到iOS 4.0。
- 如果您的網站必須支持的iOS 3.1.3用戶（這是可能的），如果需要的組件比25.6KB較大，或者如果所有組件的總規模超過281.6KB較大，可以考慮使用HTML5的應用程序緩存 ， localStorage ，或數據庫存儲來存儲您的組件。 Kessinger亞歷克斯最近的銳博客後， 在脫機應用程序中使用YUI的3 ，您可能會感興趣銳3開發商考慮這種做法。
- 做自己的測試。不要想當然地認為這些結果適用於任何測試的瀏覽器或設備的任何未來版本。 使用這些結果作為一個起點，但驗證自己之前，您對移動緩存限制的假設為基礎的重大決策。 閃電般的速度在移動瀏覽器世界的變化，因此本研究將有一個保質期很短。
我做我的測試代碼可以在GitHub上 ，我鼓勵你使用它，叉，分享你所學到的。
徵集文件
瀏覽器製造商，請考慮記錄和發布瀏覽器的緩存限制。 在桌面的世界裡，這些限制通常是如此之高，是一個非問題，文件沒有必要。 在移動世界中，瀏覽器緩存的限制是重要的信息，Web開發人員必須具有引人注目的特性，以創造高性能的網站。
localStorage和應用程序緩存等新功能的限制，通常是很好的證明。 請延長這一級別的文件以及組件緩存。
共享和擴展： 書籤del.icio.us Digg它！ | reddit！
19評論
很抱歉，評論已被封閉，在這個時候。
YUI庫在Twitter
翻譯
最近的帖子
檔案：
- 2012年5月 （3）
- 2012年4月 （13）
- 2012年3月 （6）
- 2012年2月 （7）
- 2012年1月 （8）
- 2011年12月 （7）
- 2011年11月 （12）
- 2011年10月 （4）
- 2011年9月 （9）
- 2011年8月 （6）
- 2011年7月 （7）
- 2011年6月 （8）
- 2011年5月 （6）
- 2011年4月 （10）
- 2011年3月 （8）
- 2011年2月 （5）
- 2011年1月 （10）
- 2010年12月 （24）
- 2010年11月 （21）
- 2010年10月 （11）
- 2010年9月 （17）
- 2010年8月 （18）
- 2010年7月 （8）
- 2010年6月 （11）
- 2010年5月 （11）
- 2010年4月 （22）
- 2010年3月 （22）
- 2010年2月 （16）
- 2010年1月 （8）
- 2009年12月 （9）
- 2009年11月 （29）
- 2009年10月 （14）
- 2009年9月 （12）
- 2009年8月 （4）
- 2009年7月 （5）
- 2009年6月 （7）
- 2009年5月 （7）
- 2009年4月 （7）
- 三月2009 （15）
- 2009年2月 （10）
- 2009年1月 （7）
- 2008年12月 （11）
- 2008年11月 （12）
- 2008年10月 （16）
- 2008年9月 （4）
- 2008年8月 （9）
- 2008年7月 （12）
- 2008年6月 （11）
- 2008年5月 （12）
- 2008年4月 （11）
- 2008年3月 （7）
- 2008年2月 （10）
- 2008年1月 （6）
- 2007年12月 （12）
- 2007年11月 （6）
- 2007年10月 （5）
- 2007年9月 （8）
- 2007年8月 （6）
- 2007年7月 （3）
- 2007年6月 （7）
- 2007年5月 （12）
- 2007年4月 （8）
- 2007年3月 （7）
- 2007年2月 （7）
- 2007年1月 （8）
- 2006年12月 （5）
- 2006年11月 （6）
- 2006年10月 （11）
- 2006年9月 （4）
- 2006年8月 （5）
- 2006年7月 （2）
- 2006年6月 （3）
- 2006年5月 （7）
- 2006年4月 （2）
- 2006年3月 （1）
- 2006年2月 （14）
評論政策
我們鼓勵貢獻意見，對博客上的談話。 請注意，雅虎可能在我們的全權，刪除的意見，如果他們是題外話，不適當的，或違反我們的服務條款 。
成為一個Yahoo!
你是一個天才的工程師，產品經理，或設計師，尋找自己沉浸在一個充滿創意和樂趣的環境嗎？ 然後來找到一個與我們的工作 。
元：
偉大的東西，這樣做的感謝，瑞安！
雖然廠商等著聽你的文檔調用，有這些檢查添加到browserscope.org的會很酷。 志願者嗎？ :)
斯托揚 - 6月28日，2010 ＃
感謝發布這些結果！ 我自己跑了類似的研究，最近也由Android是如何處理緩存的組件，而倖存下來，即使手機電源循環留下深刻的印象。
我在我的研究還發現，這是至關重要的內存高速緩存“磁盤高速緩存，其中後者度過一個完整的瀏覽器，重新啟動或電源週期之間的區別。 內存緩存駐留在內存中，當用戶瀏覽從頁面，我發現，這個用例的元件尺寸更大（我測試了2MB元件尺寸）。 與緩存控制，不遠的將來屆滿，並去除ETAGS，瀏覽從頁面既不移動Safari也不機器人將使往返服務器。 但是幾分鐘後，這兩個瀏覽器會來回檢查最大的組成部分（在這種情況下，2MB），並在服務器的狀態，會回送一個304，表明該文件仍然居住在客戶端的內存。 在幾分鐘的過程中，瀏覽器繼續做降序根據組件的大小，每個組件。
我為TechPulse紙的研究，但我會看到，如果我能更好地組織我的發現，並將其發布。
最後一個念頭：這可能是有趣的，看看研究的Android 1.5 1.6，遺憾的是，這些代表廣大Android用戶。 根據最新的官方統計在Android文檔（抱歉，我不能現在提供的鏈接），這些用戶代表剛剛超過50％的Android用戶。 從我的理解，這代表了很多用戶的webOS用戶相比，所以只是Android的1.5/1.6擴展研究可能更有關。
最後，我的筆記本電腦作為道歉是在店裡，我在我的iPhone輸入。 我活該金牌或什麼的！
戴維·卡爾霍恩 - 6月28日，2010 ＃
衛生署，我忘了提，我不認為這是一個意外，iPhone是如此可怕與緩存（緩存傳統，反對新的緩存技術）。 我認為他們已經這樣做有針對性，有力地推動了信封，就像他們已經不支持Flash。 它基本上是迫使開發人員學習如何使用緩存清單和本地存儲，就像拆除的Flash強迫開發人員學習如何使用新的CSS3的變換和動畫。
戴維·卡爾霍恩 - 6月28日，2010 ＃
還有一個小錯字在“測試兩個設備已32MB快閃記憶體”，應改為32GB。
感謝更新的結果，這是非常有幫助！
尼古拉斯- 6月28日，2010 ＃
斯托揚：好主意！
大衛：有趣的。 我沒有太多的時間讓我的要求之間的傳遞，所以我沒有看到你所描述的驗證請求。 我很想看到你的發現的其餘部分。
尼古拉斯：良好的漁獲物。 我已經更新後修正。 謝謝！
評論由瑞安格羅夫 - 6月28日，2010 ＃
我可以證實，缺乏對webOS的緩存。 這件事甚至不會緩存一個簡單的頁面（像這樣），可靠。 ：（
理查德 - 6月28日，2010 ＃
尼斯的工作瑞恩
菲利普·特利斯 - 6月28日，2010 ＃
偉大的文章！ 感謝瑞安。
但是，我給它一個為我的“3G/3GS 3.1.3”的嘗試，他們似乎正確的緩存資源。
你的意思是“第一代的iPhone”，作為2G iPhone沒有你？
我想，即使在3.1.3操作系統，3G/3GS的行為比2G（1根）不同。
我希望這可以幫助。
杜安- 6月29日，2010 ＃
因此，Android擁有最好的瀏覽器，甚至是Flash。 傅iPaid！
瑞安不錯的工作，並非常有用。
費利克斯·內格爾 - 6月29日，2010 ＃
偉大的工作，但我認為這不是一個很好的測試。 用戶很少點擊一個特定的IMG或樣式表的URL - 而不是他們在頁面間導航。 要更相關的測試應該看看如何在典型的Web工作流緩存行為。 大衛，我跑測試移動Safari表明大量資源（1MB）高速緩存，正如我在不同的頁面導航。 這是一個較為典型的用戶場景。 所以說iPhone 3只的高速緩存52K似乎誤導，例如。 至少，我們需要另一列。 這是偉大的代碼是在GitHub上，但如果你有一個託管版本的測試，人們可以嘗試，它會更好。 尼斯的工作 - 但我不認為這明確什麼是真正的用戶。 平安我直接和我們能出更詳盡的測試設計的範圍。
史蒂夫Souders - 6月29日，2010 ＃
史蒂夫：我很想聽聽你的結果和你的想法為改善測試方法。 我給你發一封電子郵件。
評論由瑞安格羅夫 - 6月29日，2010 ＃
“頁面緩存出現對個別網頁的大小沒有限制，興高采烈地緩存每個字節，我把它，直到可用內存被耗盡，瀏覽器崩潰。”
這是崩潰可取的行為呢？ iOS和WebOS的瀏覽器崩潰？ 只是想更吝嗇的緩存限制可能旨在限制崩潰，我不記得曾經有我的Mobile Safari崩潰。
費利克斯，怎麼這些結果意味著Android有“最好的瀏覽器”？ 還有很多“最佳”不僅僅是緩存行為。
戴- 6月30日，2010 ＃
@戴：崩潰是決不可取的，但在這種情況下，採取了5MB或更大的元件造成問題。 第一代的iPhone的Safari移動往往有大約5MB的問題，以及大約10MB的3GS，但我不能讓它崩潰的iPhone 4，即使在20MB。 Nexus One的Android的傾向開始有大約10MB的問題。 webOS的出現的頁面緩存的大小限制其他人一樣，並沒有崩潰，但正如我在文章中寫道，它有其自身的問題。
由於也參與了測試，下載的數據顯示，這會導致內存使用。 我不希望同樣的行為與不顯示，或者只是下載到文件系統的資源。
評論由瑞安格羅夫 - 6月30日，2010 ＃
關於iOS和iPhone一樣，iPad，和iPod touch：使用ICAB。
ICAB瀏覽器的任何移動平台上最好的移動瀏覽器高速緩存。 它將存儲整個網頁，所以沒有什麼需要重新下載。 你可以選擇保存整個網頁網站。 它有標籤和其他特徵，使類似桌面瀏覽器。
ICAB。
這是一個非常令人滿意的網頁瀏覽經驗的答案。
評論由詹姆斯KATT - 7月1日起，2010 ＃
您好！ 謝謝你檢討。 由於Android Market上還有許多其他的瀏覽器，除了股票之一，我覺得很有道理測試其他廣泛使用的，例如像海豚[高清]瀏覽器。 我最近發現，海豚包括東西緩存到SD卡的選項...
弗拉基米爾·凱爾曼 - 7月2日，2010 ＃
我謹向你的努力和工作，瑞安，但也呼應史蒂夫的意見。 期待你們生產什麼。
注意確保，如果你知道：Android瀏覽器的磁盤緩存算法是不實際的webkit回購（網絡瀏覽器的Java層處理不WebKit的C / C + +層）。 在CacheManager.java看http://bit.ly/azhsGH中。 大致的算法，每5個網絡請求，如果磁盤高速緩存是6MB更大它被修剪。 你還可以看到不斷CACHE_MAX_SIZE，從而限制了磁盤高速緩存組件大小2MB像你發現的研究。 我不會感到驚訝，如果你經歷的崩潰可能與6MB修剪限制。 （奇怪的是，我知道這是因為我曾經有一個緩存漏洞在客戶端的操作系統的源來解決。）
無論如何，我敢肯定，你知道，這是什麼意思是，在實踐中，它可能很難扭轉工程師的精確緩存的限制（如機器人，你的結果可能不同，這取決於你是否是第五個網絡請求 - 誰知道iphone的算法是什麼），雖然破譯一些實用的指引，就像你在這裡做了，並要求製造商發布的仍然是有用的。
評論由裕祥阿南德 - 7月2日，2010 ＃
裕祥：Android的額外細節的感謝！ 這是非常有益的。 史蒂夫和我目前正在研究一些新的考驗，並希望能夠盡快擺脫更多的光線。
評論由瑞安格羅夫 - 2010年7月2日， ＃
我也很好奇，如果的UIWebView的人可以在iOS應用包括移動Safari瀏覽器相同的限制。 一個stackoverflow問題，表示在一個UIWebView HTML5緩存清單不起作用。
評論由凱文Hakanson - 2010年7月6日， ＃
感謝發布這些結果！ 它基本上是迫使開發人員學習如何使用緩存清單和本地存儲，就像拆除的Flash強迫開發人員學習如何使用新的CSS3的變換和動畫。
技術博客 - 7月18日，2010 ＃