Yahoo User Interface Blog (YUIBlog)

Mobiele browser cache Limits, Revisited

In Mobile Browser Cache Limits: Android, iOS, en webOS , deelde ik de resultaten van mijn pogingen om de browser cache beperkingen op Android, IOS, en webOS apparaten te bepalen. Aan het eind van het artikel, schreef ik:

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.

Zo blijkt, dat was een goed advies: de dag nadat het artikel werd gepost, Steve Souders commentaar dat hij proeven met een andere methode die was meer representatief is voor een real-world web workflow lopen en had gekregen verschillende resultaten.

Nieuwe methodologie

Mijn betrokkenen originele methodologie navigeren rechtstreeks naar een willekeurig gegenereerde pagina van een bepaalde grootte, geserveerd met een text/html content type. De resultaten met behulp van deze methodiek zijn betrouwbaar reproduceerbaar (behalve op webOS), maar als Steve heeft opgemerkt, gebruikers niet rechtstreeks naar CSS en JavaScript-bestanden. Mijn veronderstelling dat de grenzen voor directe navigatie naar een HTML-bron waren dezelfde als de beperkingen voor externe CSS en JavaScript onjuist was, dus zelfs al de resultaten van mijn testen geldig waren, waren ze niet breed toepasbaar.

In de loop van vele IM-sessies, meerdere e-mails, en een paar telefoontjes, Steve en ik werkte een nieuwe testmethodologie. Ik implementeerde een versie van het op de top van mijn cache toetsingskader , dan Steve geïmplementeerd een versie in staat is van het publiceren van resultaten aan Browserscope .

In de nieuwe testen, laden we een HTML-pagina die verwijst naar een willekeurig gegenereerde CSS of JavaScript-component van een bepaalde omvang. Dan varen we naar een tweede HTML-pagina die dezelfde component en controleert of het geladen was uit de cache geladen. Om te bepalen of een component is geladen uit de cache, slaan we een timestamp in een cookie op elk verzoek; als de tijdstempel wordt bijgewerkt de tweede keer dat we last van de component, we weten dat het verzoek raakte de server, wat betekent dat het onderdeel was niet geladen uit de cache.

Nieuwe resultaten

We vonden dat alle mobiele browsers die we hebben getest aanzienlijk hogere cache limieten voor externe bronnen belast door een pagina dan ze deden voor een HTML-pagina zelf had. Dit is uitstekend nieuws voor de mobiele web-ontwikkelaars.

Onderstaande tabel illustreert onze bevindingen:

Merk op dat 4MB was de grootste maat die we hebben getest, en alle iOS-apparaten in de cache 4MB componenten. De eigenlijke cache limiet voor deze apparaten kan groter zijn dan 4MB. Ook webOS op de Palm Pre Plus consistente resultaten gaf in deze test, terwijl het had wat problemen in de vorige test.

Het is mogelijk dat de veel lagere limieten mijn vorige test toonde voor het HTML-componenten op iOS kan duiden op het gebruik van een RAM-cache voor die componenten, terwijl de veel hogere limieten voor CSS / JS componenten in deze test kan het gebruik van een disk cache aan te geven, maar dit is slechts gissen. Android, althans, lijkt op een schijf cache te gebruiken in beide gevallen, omdat de cache overleeft kracht cycli.

Nieuwe Aanbevelingen

Op basis van deze nieuwe resultaten, gekoppeld aan de resultaten van mijn vorige tests, bied ik de volgende bijgewerkte reeks aanbevelingen:

• Gebruik verre toekomst cache afloop headers. Dit zal de browser voorkomen dat een voorwaardelijke GET-aanvraag te versturen.
• Probeer HTML-pagina's te beperken tot 25.6KB of minder als je wilt dat ze worden gecached, sinds de vorige tests is gebleken dat deze limiet opgelegd door iOS 3.2 op de iPad-was de laagste HTML-bron beperken van de geteste apparaten.
• Houd CSS en JS componenten dan 1 MB. Natuurlijk, 1MB is enorm en je componenten moeten worden veel kleiner dan dit, maar splitsen van een component niet de moeite in afzonderlijke verzoeken tot het belang van cacheability, tenzij de grootte van aanpak 1MB.
• Overweeg het gebruik van de HTML5-applicatie cache als het belangrijk dat uw componenten blijven in de cache voor een lange tijd, of over de macht cycli.
• Doe je eigen test. Ik benadrukte het belang van dit in mijn vorige artikel en ik zal het hier weer stress. Gebruik deze resultaten als uitgangspunt, maar controleren ze zelf voordat je belangrijke beslissingen op basis van hen.

Zoek gesprekken: Bloglines | technorati

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