Yahoo! User Interface Blog (YUIBlog)

Mobile Browser-Cache-Limits: Android, iOS, webOS und

Update (12. Juli 2010): Während die Ergebnisse in diesem Artikel beschriebenen präzise für HTML-Seiten sind, haben neue Tests sehr unterschiedliche Cache-Grenzwerte für CSS und JS Ressourcen aufgedeckt. Die aktualisierten Ergebnisse sind in der Mobile Browser-Cache-Limits, Revisited .

Im Frühjahr 2008 schrieb Wayne Shea und Tenni Theurer eine YUI Blog-Post auf iPhone Cachefähigkeit , in denen sie die Ergebnisse der Forschung geteilt in verschiedene Merkmale und Grenzen von Mobile Safari-Cache in iPhone OS 1.x Unter anderem fanden sie, dass einzelne Komponenten größer als 25KB nicht zwischengespeichert wurden, und dass es eine maximale Cache-Größe von insgesamt zwischen 475KB und 500KB.

Seitdem hat sich viel verändert. Wir haben gesehen, zwei neue Major-Releases und viele kleinere Versionen des iPhone OS (jetzt iOS), und mehrere andere mobile Geräte mit sehr fähigen Browser erschienen, um das iPhone herauszufordern. Stoyan Stefanov gefunden, Ende 2009, dass der iPhone-Cache Grenzen verändert hatte (leider zum Schlechten). Aber wo kommen die Dinge jetzt stehen? Und was ist mit den Nicht-IOS-Browser?

Hintergrund

Browser haben zwei Arten von Caches, die wir mit für die Zwecke dieser Tests sind besorgt:

• Die Komponente Cache oder Cache-Objekt, speichert einzelne Dateien. HTML, CSS, JavaScript und alle Bilder in das Bauteil Cache zu gehen. Immer, wenn es eine dieser Komponenten muss der Browser überprüft zunächst den Cache, bevor sie eine Netzwerk-Anfrage.
• Die Seiten-Cache, der auch als Vor / Zurück-Cache genannt, speichert eine ganze Seite und alle seine Komponenten, sowie deren aktuellen Status. Wenn Sie das vor oder zurück-Taste verwenden, wird der Browser die Seite aus dem Seiten-Cache, wenn möglich zu laden.

Das HTML5-Anwendungs-Cache ist eine andere Art von Cache, die weitgehend von mobilen Browsern unterstützt wird. Browser-Hersteller bereits einen guten Job machen zu dokumentieren die Grenzen des Anwendungs-Cache, so dass ich es nicht in meinen Tests. Mehr über den Antrag später Cache.

Geräte getestet

Getestet habe ich die folgenden mobilen Browser / Plattform-Kombinationen:

• Android 2.1 (Nexus One)
• Mobile Safari auf iOS 3.1.3 (iPhone 1. Generation)
• Mobile Safari auf iOS 3.2 (iPad)
• Mobile Safari auf iOS 4.0 (iPhone 3G)
• Mobile Safari auf iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Hinweis: Mit Ausnahme der Mobile Safari auf iOS 4.0 testete ich nur ein Gerät in jeder Kategorie. Wenn es Unterschiede zwischen den einzelnen Geräten oder Unterschiede in installierter Software über das Betriebssystem basiert sind, würde meinen Tests nicht erkennen, diese Variationen. Diese speziellen Geräte wurden getestet, weil sie die, die ich für den Zugriff hatte bist, nicht, weil ich ihnen wichtiger zu sein als andere Geräte zu berücksichtigen.

Methodik

Cache-Test ist mühsam, aber relativ einfach.

Ich schrieb einen winzigen Sinatra app ( Gabel, die sie auf GitHub! ), die eine Antwort, bestehend aus einem angeforderte Anzahl von Pseudo-alphanumerische Zeichen und Leerzeichen erzeugt. Die Antworten können entweder serviert oder unkomprimierten gzipped werden. Die folgenden fernen Zukunft Ablauf-Response-Header gesendet werden, um sicherzustellen, dass alle Antworten berücksichtigt werden zwischengespeichert werden:

 Cache-Control: max-age = 315360000
 Gültig bis: Fr, 1. Mai 2020 03.47.24 GMT

In meinem lokalen Netzwerk, habe ich dann manuell die folgenden Schritte auf jedem Gerät, um die Komponente Cache-Test durchgeführt:

1. Laden Sie den Cache-Test-Index-Seite.
2. Tippen Sie auf einen Link zu einer Komponente von einer bestimmten Größe, angefangen von 5KB zu 20MB, und warten Sie, Beladung bis zum Ende.
3. Tippen Sie auf die Schaltfläche Zurück.
4. Tippen Sie auf den gleichen Link wieder. Beobachten Sie, ob die zufälligen Zeichen identisch sind, und ob der Server-Konsole druckt einen Log-Eintrag für einen Antrag, um festzustellen, ob die Komponente zwischengespeichert werden in Schritt 2 war.
5. Wiederholen und passen Komponente Größen wie nötig, um die maximale Bauteilgröße, die zwischengespeichert wird bestimmen.

Um die Seite Cache zu testen, führte ich im Wesentlichen die gleichen Schritte, außer dass anstelle der Erschließung erneut auf den Link in Schritt 4, klopfte ich den Browser-Vorwärts-Taste, wodurch es zu den Seiten-Cache anstatt die Komponente Cache verwenden.

Unterstützung für ETag und Last-Modified wurde durch Optimierungen der Server, um die entsprechende Nachricht bestimmt ETag oder Last-Modified -Response-Header (in separaten Tests) und um die Zukunft weit-Ablauf-Header zu verzichten. Ich habe dann inspizierten die Request-Header vom Server empfangen, um sicherzustellen, dass der Browser die erwartete geschickt If-None-Match oder If-Modified-Since -Header auf Schritt 4.

Ergebnisse

Getestet habe ich mit gzip beide aktiviert und deaktiviert, aber ich fand, dass gzip keine Auswirkungen auf Cachefähigkeit auf jedem Gerät hatte. Die unkomprimierte Komponente die Größe kommt es in allen Fällen, unabhängig davon, ob diese Komponente bedient wird gzip. Als solche sind alle hier genannten Größen Komponente unkomprimierte Größe.

Die nachstehende Tabelle zeigt meine generellen Feststellungen.

Androide

Der Android-Browser zeigte die beste Cache-Verhalten aller Geräte getestet. Während es keine Grenze für die Größe der einzelnen Komponenten auferlegt wird, scheint die Cache-Größe auf etwa 2 MB beschränkt werden, was bedeutet, dass die einzelnen Komponenten wirksam zu 2 MB, beschränkt.

Die Seiten-Cache schien keine Grenze für die Größe der einzelnen Seiten zu verhängen, glücklich jedes Byte Caching ich es warf, bis der verfügbare RAM erschöpft war und der Browser abgestürzt ist.

Ich war angenehm überrascht, dass Android die Komponente Cache beide Browser neu gestartet und Macht Zyklen überstanden, war ein Kunststück, keiner der iOS-Geräte in der Lage, um zusammenzupassen.

Mögliche Einschränkung: Eine Überprüfung der Android WebKit-Source-Tree führt mich zu glauben, dass ihre Grenzen Cache kann bezogen auf die Menge an RAM und / oder Flash-Speicher auf dem jeweiligen Gerät, auf dem es läuft anzupassen. Wenn das stimmt, kann diese Zahlen nur anwendbar auf dem Nexus One. In der Tat, wenn der Cache-Größe auf ungenutzten Speicher anstatt Gesamtspeicher anpaßt, kann diese Zahlen nur dann anwendbar, meine Nexus One.

Ich könnte falsch sein, aber die Unterschiede in den Testergebnissen iOS 4.0 auf dem iPhone 3GS und iPhone 4 unterstützen diese Theorie. (Android und Mobile Safari sind sowohl WebKit-basierten Browsern, so dass sie dieses Verhalten gemeinsam haben.) Wenn Sie sich mit dem WebKit-Quelle sind und kann mehr Licht in diese Schuppen, nehmen Sie bitte mit mir in Verbindung.

iOS

Die Ergebnisse variierten wild über die drei neuesten Versionen von iOS. Erstaunlicherweise hat Mobile Safari auf iOS 3.1.3 nicht zwischenspeichern Komponenten jeder Größe, obwohl sie eine scheinbar unbegrenzte Seite Cache-Größe. Dies ist beunruhigend, da heißt es iOS 3.1.3 Benutzer werden wahrscheinlich immer eine suboptimale Browsing-Erlebnis, besonders wenn sie benutzen kein wifi. Die unbegrenzte Seite Cache-Größe tut wenig gut hier, denn es kommt nur ins Spiel, für Vor / Zurück-Navigationen. Dieses Verhalten ist eine signifikante Veränderung aus, was andere beobachtet in früheren IOS-Releases und ich kann mir keinen guten Grund dafür, weshalb ich vermute, dies könnte ein Fehler sein.

Mobile Safari auf iOS 3.2 (die nur auf dem iPad) zeigt nicht diesen Fehler. Seine 25.6KB Komponente Limit und ~ 281.6KB Gesamt-Cache Limit sind besser als nichts, aber sie scheinen immer noch dürftig im Vergleich zu den anderen Geräten getestet. Einzigartig unter den iOS-Geräten erscheint das iPad, um die Größe der Seiten in der Seiten-Cache zu begrenzen, um 25.6KB, das gleiche wie seine Bestandteile Größenbeschränkung.

Mobile Safari auf iOS 4.0 ausgestellt unterschiedliche Grenzen auf dem iPhone 3GS und auf dem iPhone 4, was bedeutet, dass die Grenzen der verfügbaren RAM (das iPhone 3GS verfügt über 256 MB, während das iPhone 4 hat 512 MB; beide Geräte getestet hatte 32 GB Flash-Speicher) anzupassen gründet, setzt . Auf dem iPhone 3GS, iOS 4.0 hat eine Größenbeschränkung 51.199KB Komponente und eine ~ 1.05MB insgesamt Komponente Cache-Größe.

Auf dem iPhone 4 war die Komponente Größenbeschränkung fast genau zwei Mal die Grenze auf dem iPhone 3GS, bei 102.399KB. Die gesamte Komponente Cache-Größe lag bei ca. 1,9 MB. Vielleicht, weil iOS 3.2 und iOS 4.0 separat entwickelt wurden, sondern verzweigt von einem gemeinsamen Vorfahren, erscheint das iOS 4.0 Seite Cache-Größe nur durch den verfügbaren Arbeitsspeicher auf beiden Geräten getestet, genauso wie iOS 3.1.3 begrenzt werden.

Keine der iOS-Geräte erhalten die Inhalte des Cache über erzwungene Browser neu gestartet oder das Gerät Macht Zyklen, obwohl sie den Cache habe nur bewahren, wenn Switching-Anwendungen, ohne tatsächlich zu töten Sie den Browser.

webOS

Meine Testergebnisse waren so auf webOS inkonsequent, dass ich wenig Vertrauen zu ihnen haben. Ich habe aufgenommen, was ich nur wenige Daten zu sammeln, rein aus Gründen der Vollständigkeit verwaltet. Bitte nehmen Sie es mit einer saftigen Körnchen Salz.

Soweit ich feststellen können, war, könnte webOS haben eine individuelle Komponente Größenbeschränkung von ca. 1MB, mit einer passenden Seite Größenbeschränkung in der Seiten-Cache. Ich konnte Koax- If-None-Match oder If-Modified-Since -Anfrage-Header von webOS, so dass es nicht unterstützt impliziert ETag und Last-Modified .

Bei einigen Tests stellte sich heraus, dass die maximale Komponente webOS Größe von mehr als 1MB war, aber das war inkonsistent. Soweit ich das beurteilen kann, erscheint webOS auf einen fiesen Bug, bei dem haben, nachdem eine bestimmte Punkt-möglicherweise, wenn die maximale Cache-Größe insgesamt erreicht-die Cache wird gerade komplett aufhört zu arbeiten zusammen, bis sich das Telefon-und wieder eingeschaltet. In einigen Fällen sogar Macht Radfahren nicht fix den Cache zu Bruch, so dass ich schließlich aufgegeben hat, um die genaue Ursache des Problems und die genauen Grenzen des webOS-Cache einzurichten.

Empfehlungen

Basierend auf diesen Ergebnissen, biete ich folgende Empfehlungen an jedermann die Entwicklung von Webanwendungen für die getesteten Geräte:

• Verwenden Sie far-future-Cache Ablauf-Header. Dies wird der Browser mit, um eine bedingte GET-Anfrage zu senden und wird in Cachefähigkeit webOS, der nicht die Verbesserung verhindern ETag oder Last-Modified .
• Zumindest solange, bis iOS 4.0 kommt auf dem iPad, versuchen, einzelne Komponente Größen zu 25.6KB oder weniger zu begrenzen, unkomprimiert. Und fordern Sie Ihre iPhone-Nutzer auf iOS 4.0 so schnell wie möglich aktualisieren.
• Wenn Ihre Website iOS 3.1.3 Nutzer (was wahrscheinlich ist) unterstützen müssen, wenn sie größer sind als Komponenten 25.6KB erfordert, oder wenn die Gesamtgröße all Ihrer Komponenten ist größer als 281.6KB, sollten Sie die HTML5-Anwendungs-Cache, localStorage , oder die Speicherung in Datenbanken zu speichern Sie Ihre Komponenten. Alex Kessinger neueste YUI Blog-Post, Einführung in die Nutzung YUI 3 im Offline-Anwendungen , könnten von Interesse für YUI 3 Entwickler der Prüfung dieses Ansatzes sein.
• Machen Sie Ihre eigene Tests. Sie nicht davon aus, dass diese Ergebnisse für alle künftigen Version von jedem der getesteten Browsern oder Geräten anwenden. Mit diesen Ergebnissen als Ausgangspunkt, sondern überprüfen sie sich, bevor Sie wichtige Entscheidungen auf Annahmen über mobiles Cache Einschränkungen basieren machen. Die mobilen Browser Welt verändert sich in einem Blitz-Tempo, so dass diese Forschung wird eine sehr kurze Haltbarkeit.

Ich habe mein Test-Code verfügbar auf GitHub gemacht und ich ermutige Sie, es zu benutzen, sie berappen, und teilen, was du lernst.

Aufruf zur Dokumentation

Browserhersteller, beachten Sie bitte die Dokumentation und Veröffentlichung von den Cache Ihres Browsers Grenzen. In der Desktop-Welt, wo diese Grenzen sind typischerweise so hoch, dass kein Thema ist, wurde Dokumentation nicht erforderlich. In der mobilen Welt, sind Browser-Cache Grenzen lebenswichtige Informationen, dass Web-Entwickler müssen, um performante Websites mit überzeugenden Eigenschaften zu schaffen.

Die Grenzen der neuen Features wie localStorage und Anwendungs-Cache werden in der Regel gut dokumentiert. Ergänzen Sie bitte diese Ebene der Dokumentation zu dem Bauteil-Cache als auch.

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!