Yahoo User Interface Blog (YUIBlog)

Mobiele browser cache Limits: Android, iOS en webOS

Update (12 juli 2010): Hoewel de resultaten beschreven in dit artikel zijn nauwkeurig voor HTML-pagina's, nieuwe tests hebben uitgewezen zeer verschillende cache grenzen voor CSS en JS middelen. De bijgewerkte resultaten zijn beschreven in Mobile Browser Cache Limits, Revisited .

In het begin van 2008, Wayne Shea en Tenni Theurer schreef een YUI blog post op de iPhone Cacheability waarin zij de resultaten van het onderzoek verdeeld in verschillende kenmerken en beperkingen van de cache-Mobile Safari in iPhone OS 1.x. Onder andere dingen, vonden zij dat de afzonderlijke componenten groter is dan 25KB cache niet waren, en dat er een maximale totale cache grootte van tussen de 475KB en 500KB.

Er is veel veranderd sindsdien. We hebben gezien twee nieuwe grote releases en tal van kleinere releases van het iPhone OS (nu IOS), en diverse andere mobiele apparaten met zeer capabele browsers zijn verschenen op de iPhone uitdaging. Stoyan Stefanov gevonden, eind 2009, dat de iPhone de cache van grenzen was veranderd (helaas, voor het erger). Maar waar doen dingen nu staan? En wat te denken van deze niet-iOS browsers?

Achtergrond

Browsers hebben twee soorten caches dat we bezig met voor de toepassing van deze tests:

• De component cache, of object cache, winkels afzonderlijke bestanden. HTML, CSS, JavaScript, en beelden gaan allemaal in de component cache. Wanneer het een van deze onderdelen nodig heeft, de browser controleert eerst de cache voor het maken van een netwerk te vragen.
• De pagina cache, ook wel bekend als de back / forward cache, slaat een hele pagina en alle onderdelen daarvan, evenals hun huidige toestand. Wanneer u de rug of forward knop te gebruiken, zal de browser de pagina te laden van de pagina cache indien mogelijk.

De HTML5 applicatie cache is een ander type cache dat op grote schaal wordt ondersteund door mobiele browsers. Browser makers nu al doen een goede baan van het documenteren van de grenzen van de toepassing cache, dus ik heb niet op in mijn testen. Meer over de toepassing cache later.

Apparaten getest

Ik testte de volgende mobiele browser / platform combinaties:

• Android 2.1 (Nexus One)
• Mobile Safari op iOS 3.1.3 (1e generatie iPhone)
• Mobile Safari op iOS 3.2 (iPhone)
• Mobile Safari op iOS 4.0 (iPhone 3G)
• Mobile Safari op iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Let op: Met uitzondering van de Mobile Safari op iOS 4.0, testte ik slechts een apparaat in elke categorie. Als er verschillen tussen individuele apparaten of verschillen op basis van geïnstalleerde software buiten het OS, dan zou mijn tests niet gedetecteerd die variaties. Deze bijzondere apparaten werden getest omdat ze degene die ik had toegang tot, niet omdat ik volgens hen belangrijker dan andere apparaten.

Methodologie

Cache testen is vervelend, maar relatief eenvoudig.

Ik schreef een klein Sinatra applicatie ( fork het op GitHub! ) die een respons, bestaande uit een gevraagde aantal van de pseudo-alfanumerieke en witruimte bytes genereert. De reacties kunnen worden bediend zowel gzipped of ongecomprimeerde. De volgende verre toekomst afloop response headers worden gestuurd om ervoor te zorgen dat alle antwoorden zijn cachen beschouwd:

 Cache-Control: max-age = 315360000
 Verloopt: Vrij 1-5-2020 03:47:24 GMT

Meer dan mijn lokale netwerk, heb ik handmatig gedaan de volgende stappen op elk apparaat aan op de component cache test:

1. Laad de cache-test index pagina.
2. Tik op een koppeling naar een onderdeel van een bepaalde grootte, variërend van 5KB tot 20 MB, en wachten tot het laden van af te maken.
3. Tik op de knop Terug.
4. Tik nogmaals op dezelfde link. Let op de vraag of de willekeurige karakters zijn hetzelfde, en of de server console een regel voor een verzoek om te bepalen of de component werd opgeslagen in stap 2 prints.
5. Herhalen en aan te passen component maten als nodig is om de maximale grootte van component dat zal worden gecached vast te stellen.

Voor het testen van de pagina cache, heb ik uitgevoerd in wezen dezelfde stappen, behalve dat in plaats van tikken op de koppeling weer in stap 4, tikte ik de browser naar voren knop, waardoor het naar de pagina cache in plaats van de component cache te gebruiken.

Ondersteuning voor ETag en Last-Modified werd bepaald door het instellen van de server naar de juiste sturen ETag of Last-Modified response headers (in afzonderlijke tests) en de verre toekomst verlopen headers weglaten. Vervolgens heb ik onderzocht het verzoek headers ontvangen door de server om te controleren of de browser de verwachte stuurde If-None-Match of If-Modified-Since headers op stap 4.

Resultaten

Ik heb getest met gzip zowel de in-en uitgeschakeld, maar ik vond dat de gzip geen effect op cacheability op elk apparaat had. De ongecomprimeerde component grootte is waar het om gaat in alle gevallen, ongeacht of niet, dat onderdeel is gzipped geserveerd. Als zodanig zijn alle componenten maten die hier genoemd zijn niet-gecomprimeerde formaten.

Onderstaande tabel illustreert mijn algemene bevindingen.

Android

De Android-browser vertoonde de beste cache gedrag van alle geteste apparaten. Hoewel het lijkt geen grens te stellen aan de grootte van de afzonderlijke componenten, de totale cachegrootte lijkt te worden beperkt tot ongeveer 2MB, wat betekent dat afzonderlijke componenten effectief worden beperkt tot 2MB ook.

De pagina cache bleek geen limiet stellen aan de grootte van de afzonderlijke pagina's, gelukkig elke byte caching gooide ik op het tot het beschikbare RAM-geheugen is uitgeput en de browser is gecrasht.

Ik was aangenaam verrast te zien dat Android component cache van zowel de browser opnieuw wordt opgestart en macht cycli overleefde, een prestatie die geen enkele van de iOS-apparaten in staat was aan te passen.

Mogelijke valkuil: Een overzicht van Android's WebKit source tree leidt me om te geloven dat de cache grenzen kunnen aanpassen op basis van de hoeveelheid RAM-geheugen en / of flash-geheugen beschikbaar is op de specifieke apparaat waarop het draait. Als dat waar is, kunnen deze cijfers alleen van toepassing op de Nexus One. In feite, als de cache grootte aanpast op basis van ongebruikt geheugen in plaats van totaal geheugen, kunnen deze cijfers alleen voor mijn Nexus One.

Ik zou vergissen, maar de verschillen in de iOS 4,0 testresultaten op de iPhone 3G en iPhone 4 ondersteunen deze theorie. (Android en Mobile Safari zijn beide WebKit-gebaseerde browsers, zodat ze kunnen dit gedrag in gemeen hebben.) Als u bekend bent met de WebKit-source en kan meer licht werpen op deze, neem dan contact op met mij.

iOS

De resultaten varieerden wild over de drie meest recente versies van IOS. Verbazingwekkend, heeft Mobile Safari op iOS 3.1.3 niet in de cache componenten van elke omvang, ondanks het feit dat een schijnbaar ongelimiteerde pagina cache grootte. Dit is verontrustend, omdat het betekent iOS 3.1.3 gebruikers waarschijnlijk een suboptimaal surfervaring krijgt, vooral als ze niet zijn wifi gebruikt. De onbeperkte pagina cachegrootte doet weinig goed hier, want het komt alleen in het spel voor back / forward navigatie. Dit gedrag is een belangrijke verandering van wat anderen waargenomen in eerdere iOS releases en ik kan me niet voorstellen dat geen goede reden voor zijn, dus ik vermoedt dat dit een bug te zijn.

Mobile Safari op iOS 3.2 (die alleen beschikbaar is op de iPad) niet vertonen deze bug. De 25.6KB component te beperken en ~ 281.6KB totaal cache te beperken zijn beter dan niets, maar ze lijken nog steeds schamele in vergelijking met de andere geteste apparaten. Uniek bij iOS-apparaten, de iPad lijkt te beperken van de grootte van pagina's in de pagina cache 25.6KB, net als de samenstellende limiet.

Mobile Safari op iOS 4,0 tentoongesteld verschillende limieten op de iPhone 3G en op de iPhone 4, wat impliceert dat de grenzen aan te passen op basis van beschikbare RAM-geheugen (de iPhone 3G heeft 256 MB, terwijl de iPhone 4 heeft 512 MB; getest op beide apparaten had 32 GB flash-geheugen) . Op de iPhone 3G, iOS 4.0 heeft een 51.199KB component limiet en een ~ 1.05MB totaal component cache grootte.

Op de iPhone 4, het onderdeel limiet was bijna precies twee keer de limiet voor de iPhone 3G, op 102.399KB. De totale component cache grootte van ongeveer 1,9 MB. Misschien omdat iOS 3.2 en 4.0 iOS afzonderlijk werden ontwikkeld, maar vertakt vanuit een gemeenschappelijke voorouder, de iOS 4,0 pagina cachegrootte lijkt te worden alleen beperkt door de beschikbare RAM-geheugen op beide apparaten getest, net als iOS 3.1.3.

Geen van de iOS-apparaten bewaard gebleven van de inhoud van de cache over gedwongen browser opnieuw wordt gestart of het apparaat stroom cycli, hoewel ze wel de cache te behouden wanneer alleen schakelen toepassingen zonder dat het doden van de browser.

webOS

Mijn testresultaten op webOS waren zo inconsequent dat ik weinig vertrouwen in hen hebben. Ik heb begrepen wat weinig gegevens slaagde ik erin om puur te verzamelen voor de volledigheid. Neem het met een flinke korrel zout.

Zo dichtbij als ik was in staat om vast te stellen, zou webOS een individuele component limiet van ongeveer 1 MB, met een bijpassende paginagrootte te beperken in de pagina cache. Ik was niet in staat om coax If-None-Match of If-Modified-Since verzoek headers van webOS, wat inhoudt dat hij geen ondersteuning biedt voor ETag en Last-Modified .

Op sommige tests bleek dat webOS is een maximale grootte van component was groter dan 1 MB, maar dit was inconsistent. Voor zover ik kan vertellen, webOS lijkt te hebben een vervelende bug waar, na een bepaald punt, eventueel wanneer de maximale totale cache grootte is bereikt, de cache gewoon helemaal niet meer werkt helemaal totdat de telefoon is power-gefietst. In sommige gevallen zelfs de macht fietsen niet van de cache breuk vast te stellen, zodat ik uiteindelijk gaf het proberen om de precieze oorzaak van het probleem en de exacte grenzen van het webOS cache vast te stellen.

Aanbevelingen

Op basis van deze resultaten, bied ik de volgende aanbevelingen aan iedereen die het ontwikkelen van web applicaties voor de geteste apparaten:

• Gebruik verre toekomst cache afloop headers. Dit zal de browser voorkomen dat een voorwaardelijke GET-verzoek te verzenden en zal cacheability verbeteren webOS, die geen ondersteuning biedt voor ETag of Last-Modified .
• Ten minste tot iOS 4.0 komt op de iPad, probeer dan aan de individuele component maten te beperken tot 25.6KB of minder, niet-gecomprimeerde. En drang je iPhone-gebruikers om te upgraden naar iOS 4.0 zo snel mogelijk.
• Als uw website moet ondersteunen iOS 3.1.3 gebruikers (die waarschijnlijk is), als het nodig componenten groter dan 25.6KB, of als de totale omvang van alle componenten groter is dan 281.6KB, overweeg dan het gebruik van de HTML5 toepassing cache, localStorage , of opslag in een databank om uw componenten op te slaan. Recente YUI alex Kessinger's Blog post, An Introduction to Met behulp van YUI 3 in offline toepassingen , wellicht van belang zijn voor YUI drie ontwikkelaars overweegt deze aanpak.
• Doe je eigen onderzoek. Ga er niet vanuit dat deze resultaten van toepassing op alle toekomstige versie van een van de geteste browsers of apparaten. Gebruik deze resultaten als uitgangspunt, maar controleren ze zelf voordat je belangrijke beslissingen gebaseerd op aannames over mobiele cache beperkingen. De mobiele browser wereld verandert in een bliksem tempo, dus dit onderzoek zal een zeer korte houdbaarheid.

Ik heb gemaakt mijn test-code beschikbaar op GitHub en ik moedig u aan om het te gebruiken, het vork, en wat je leert delen.

Bel voor Documentatie

Browser makers, overweeg dan documenteren en publiceren van uw browser cache van grenzen. In de desktop wereld waar die grenzen vaak zo hoog zijn als voor een non-issue te zijn, was de documentatie niet nodig. In de mobiele wereld, browser cache grenzen zijn vitale informatie die webontwikkelaars moet hebben om performante websites te maken met de aantrekkelijke mogelijkheden.

De grenzen van de nieuwe functies, zoals localStorage en de toepassing cache zijn meestal goed gedocumenteerd. Gelieve uit te breiden dit niveau van documentatie om het onderdeel cache ook.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | digg it! | reddit!