Interfaz de usuario de Yahoo! Blog (YUIBlog)

Límites móviles caché del navegador: Android, iOS y webOS

Actualización (12 de julio de 2010): Si bien los resultados descritos en este artículo son precisas para las páginas HTML, nuevas pruebas han puesto de manifiesto los límites de la caché muy diferentes para los recursos CSS y JS. Los resultados actualizados se describen en los límites de Mobile Browser Cache, Revisited .

A principios de 2008, Wayne Shea y Theurer Tenni escribió una entrada de blog de ​​YUI en almacenamiento en caché de iPhone en el que compartió los resultados de la investigación de diversas características y limitaciones de la memoria caché de Mobile Safari en el iPhone OS 1.x Entre otras cosas, encontraron que los componentes individuales más grandes que no eran 25KB caché, y que no había un tamaño máximo de caché total de entre 475KB y 500KB.

Mucho ha cambiado desde entonces. Hemos visto dos nuevos lanzamientos importantes y muchas versiones menores del iPhone OS (ahora IOS), y varios otros dispositivos móviles con navegadores de alta capacidad han surgido para desafiar al iPhone. Stoyan Stefanov encontrado, a finales de 2009, que los límites de la caché del iPhone ha cambiado (por desgracia, para mal). Pero, ¿dónde están las cosas ahora? Y ¿qué pasa con los navegadores no-IOS?

Fondo

Los navegadores tienen dos tipos de cachés que estamos preocupados por los efectos de estas pruebas:

• El caché del componente, o caché de objetos, almacena los archivos individuales. HTML, CSS, JavaScript, y todas las imágenes entra en la caché del componente. Cada vez que necesita uno de estos componentes, el navegador comprueba primero la caché antes de hacer una solicitud de red.
• La caché de la página, también conocida como la caché adelante / atrás, almacena una página entera y todos sus componentes, así como su estado actual. Cuando se utiliza la parte de atrás hacia adelante o el botón, el navegador carga la página de la caché de la página si es posible.

El caché de la aplicación HTML5 es otro tipo de caché que es ampliamente soportado por los navegadores móviles. Los fabricantes de navegadores ya lo hacen un buen trabajo de documentación de los límites de la caché de la aplicación, por lo que no se incluyen en mis pruebas. Más información sobre el caché de la aplicación más tarde.

Dispositivos de Prueba

He probado los siguientes móviles navegador / plataforma de combinaciones:

• Android 2.1 (Nexus One)
• Mobile Safari en iOS 3.1.3 (primera generación de iPhone)
• Mobile Safari en iOS 3.2 (iPad)
• Mobile Safari en iOS 4.0 (iPhone 3G)
• Mobile Safari en iOS 4.0 (iPhone 4)
• webOS 1.4.1 (Palm Pre Plus)

Nota: Con la excepción de Mobile Safari en iOS 4.0, he probado un solo dispositivo en cada categoría. Si existen diferencias entre los dispositivos individuales o las diferencias basadas en el software instalado más allá del sistema operativo, mis pruebas no detectan estas variaciones. Estos dispositivos particulares se pusieron a prueba, porque ellos son los que tuve acceso a no, porque considero que es más importante que otros dispositivos.

Metodología

Pruebas de memoria caché es tedioso, pero relativamente simple.

Escribí una pequeña aplicación Sinatra ( tenedor que en GitHub! ) que genera una respuesta que consiste en un número determinado de caracteres alfanuméricos y los bytes pseudoaleatorios espacios en blanco. Las respuestas pueden ser servidos con gzip o sin comprimir. Los siguientes extrema futuras cabeceras de respuesta de caducidad se envían para asegurar que todas las respuestas se consideran cacheable:

 Cache-Control: max-age = 315360000
 Expira: Vie, 01 de mayo 2020 03:47:24 GMT

Por encima de mi red local, entonces manualmente realiza los siguientes pasos en cada dispositivo para poner a prueba la memoria caché de los componentes:

1. Carga de la prueba de memoria caché de la página de índice.
2. Toque en un enlace a un componente de un determinado tamaño, que van desde 5 KB a 20 MB, y esperar a que termine de cargarse.
3. Pulse el botón Atrás.
4. Pulse en el enlace mismo. Observar si los caracteres al azar son los mismos, y si la consola del servidor imprime una entrada de registro para una petición, para determinar si el componente se almacenó en caché en el paso 2.
5. Repetir y ajustar el tamaño de los componentes según sea necesario para determinar el tamaño máximo que los componentes se almacenan en caché.

Para poner a prueba la memoria caché de la página, me llevaron a cabo esencialmente los mismos pasos, excepto que en lugar de pulsar el enlace de nuevo en el paso 4, hice tapping botón de avance del navegador, haciendo que se utiliza la caché de páginas en lugar de la memoria caché de los componentes.

Apoyo a la ETag y Last-Modified se determinó ajustar el servidor para enviar el caso ETag o Last-Modified cabeceras de respuesta (en las pruebas por separado) y omitir las cabeceras de vencimiento de largo en el futuro. Luego inspeccionó las cabeceras de petición recibidos por el servidor para comprobar que el navegador envía la espera If-None-Match o If-Modified-Since encabezados en el paso 4.

Resultados

He probado tanto con gzip activado y desactivado, pero me di cuenta de que gzip no tuvo efecto en almacenamiento en caché en cualquier dispositivo. El tamaño de los componentes sin comprimir es lo que importa en todos los casos, independientemente de si o no ese componente se sirve gzip. Como tal, todos los tamaños de los componentes mencionados aquí son los tamaños sin comprimir.

La siguiente tabla ilustra mis conclusiones generales.

Androide

El navegador de Android mostró el mejor comportamiento de caché de todos los dispositivos probados. Aunque parece que no limitan el tamaño de los componentes individuales, el tamaño total de caché parece estar limitada a aproximadamente 2 MB, lo que significa que los componentes individuales se limitan efectivamente a 2MB también.

El caché de la página que parecía no imponer ningún límite en el tamaño de las páginas individuales, felizmente el almacenamiento en caché cada byte que arrojó a ella hasta que la memoria RAM disponible se agotó y se estrelló contra el navegador.

Me sorprendió gratamente encontrar que la caché de Android componente sobrevivido tanto reinicia tu navegador y los ciclos de energía, un no logro de los dispositivos IOS fue capaz de igualar.

Posible advertencia: Una revisión de árbol de la fuente de Android WebKit me lleva a creer que sus límites de caché puede adaptar sobre la base de la cantidad de memoria RAM y / o memoria flash disponible en el dispositivo en particular en el que se está ejecutando. Si es cierto, estas cifras sólo pueden ser aplicables a la Nexus. De hecho, si el tamaño de la caché se adapta sobre la base de la memoria no utilizada en lugar de la memoria total, estas cifras sólo pueden ser aplicables a mi Nexus One.

Puedo estar equivocado, pero las diferencias en los resultados de la prueba iOS 4.0 en el iPhone 3G y el iPhone 4 apoyan esta teoría. (Android y Safari Mobile son navegadores basados ​​en WebKit, por lo que puede tener este comportamiento en común.) Si usted está familiarizado con la fuente de WebKit y puede arrojar más luz sobre esto, por favor ponerse en contacto conmigo.

iOS

Los resultados variaron enormemente en las tres versiones más recientes de IOS. Sorprendentemente, Mobile Safari en iOS 3.1.3 no almacenar en caché los componentes de cualquier tamaño, a pesar de tener un tamaño de página de memoria caché de apariencia ilimitada. Esto es preocupante ya que significa que los usuarios de iOS 3.1.3 es probable conseguir una experiencia de navegación óptima, sobre todo si no están usando wifi. El tamaño de la página de caché ilimitada poco sirve aquí, ya que sólo entra en juego para atrás / adelante navegaciones. Este comportamiento es un cambio significativo de lo que otros observaron en las versiones anteriores de iOS y no puedo imaginar una buena razón para ello, así que sospecho que esto puede ser un error.

Mobile Safari en iOS 3.2 (que sólo está disponible en el iPad) no presenta este error. Su límite de componentes 25.6KB y ~ 281.6KB límite de la caché total es mejor que nada, pero aún así parece insignificante en comparación con los demás sistemas. Únicamente entre los dispositivos IOS, el iPad parece limitar el tamaño de las páginas en el caché de la página de 25.6KB, al igual que su límite de tamaño de los componentes.

Mobile Safari en iOS 4.0 exhiben diferentes límites de los iPhone 3G y el iPhone 4, lo que implica que los límites adaptan sobre la base de la memoria RAM disponible (el iPhone 3G tiene 256 MB, mientras que el iPhone 4 tiene 512 MB, ambos dispositivos probados tenía 32 GB de memoria flash) . En el iPhone 3G, el iOS 4.0 tiene un límite de tamaño de los componentes 51.199KB y una ~ 1.05MB tamaño total de caché de componentes.

En el iPhone 4, el límite de tamaño de los componentes era casi exactamente dos veces el límite en el iPhone 3GS, en 102.399KB. El tamaño de los componentes de caché total fue de aproximadamente 1,9 MB. Tal vez debido a iOS 3.2 y iOS 4.0 se han desarrollado por separado, pero ramificado a partir de un ancestro común, el iOS 4.0 tamaño de caché de la página parece estar limitado sólo por memoria RAM disponible en ambos dispositivos probados, al igual que iOS 3.1.3.

Ninguno de los dispositivos IOS conserva el contenido de la caché del navegador en todos los reinicios forzados o los ciclos de alimentación de los dispositivos, aunque sí preservar la memoria caché cuando el conmutador de aplicaciones sin tener que matar el navegador.

webOS

Mis resultados de las pruebas de webOS son tan inconsistentes que tengo poca confianza en ellos. He incluido los pocos datos que logró reunir exclusivamente para el bien de la integridad. Por favor, llévelo con un grano de sal fuerte.

Lo más cerca que yo era capaz de determinar, webOS podría tener un límite de tamaño de los componentes individuales de alrededor de 1 MB, con un límite de tamaño de página en la caché de la página. No he podido convencer a If-None-Match o If-Modified-Since encabezados de la solicitud de webOS, lo que implica que no es compatible con ETag y Last-Modified .

En algunas pruebas, parece que el tamaño del webOS de componentes de máxima fue mayor de 1 MB, pero esto era incompatible. Por lo que yo puedo decir, webOS parece tener un desagradable error que, después de un cierto punto, posiblemente, cuando el tamaño total de caché máximo se alcanza-la memoria caché sólo se detiene por completo de funcionar por completo hasta que el teléfono es el poder de volver a arrancar. En algunos casos, incluso ciclos de encendido no se soluciona la rotura de caché, así que finalmente renunció a tratar de establecer la causa exacta del problema y los límites exactos de la caché de webOS.

Recomendaciones

En base a estos resultados, ofrecemos las siguientes recomendaciones a cualquier persona el desarrollo de aplicaciones web para los dispositivos probados:

• El uso de largo en el futuro las cabeceras de caducidad de la caché. Esto evitará que el navegador de tener que enviar una petición GET condicional, y mejorará el almacenamiento en caché en webOS, que no es compatible con ETag o Last-Modified .
• Por lo menos hasta iOS 4.0 llega en el IPAD, trate de limitar el tamaño de los componentes individuales de 25.6KB o menos, sin comprimir. E instar a los usuarios de iPhone para actualizar a iOS 4.0 tan pronto como sea posible.
• Si su sitio web debe ser compatible con iOS 3.1.3 los usuarios (lo cual es probable), si se requiere de los componentes más grandes que 25.6KB, o si el tamaño total de todos sus componentes es mayor que 281.6KB, considere el uso de la caché de aplicación HTML5, localStorage , o de almacenamiento de base de datos para almacenar sus componentes. Alex Kessinger reciente de YUI entrada del blog, Introducción al uso de YUI 3 en aplicaciones fuera de línea , podría ser de interés para los desarrolladores de YUI 3 teniendo en cuenta este enfoque.
• Haga su propia prueba. No asuma que estos resultados se aplican a cualquier versión futura de cualquiera de los navegadores o dispositivos probados. Utilizar estos resultados como punto de partida, pero verifique usted mismo antes de tomar decisiones importantes basadas en suposiciones acerca de las limitaciones de memoria caché móviles. Los cambios del navegador móvil del mundo a un ritmo relámpago, por lo que esta investigación tendrá una vida útil muy corta.

He hecho mi código de prueba está disponible en GitHub y os animo a usarlo, tenedor, y compartir lo que aprende.

Convocatoria de Documentación

Los fabricantes de navegadores, por favor considere la documentación y publicación de los límites de su navegador de la caché. En el mundo de escritorio, donde estos límites suelen ser tan alta como para ser un tema no, la documentación no era necesaria. En el mundo de los móviles, los límites de la caché del navegador son información vital que los desarrolladores web deben tener con el fin de crear sitios web Performant con características atractivas.

Los límites de las nuevas características como localStorage y el caché de la aplicación son bien documentados. Por favor, extender este nivel de la documentación a la caché del componente, así.

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar página con del.icio.us | Digg It! | reddit!