Yahoo! interfaz de usuario de blog (YUIBlog)

Límites de memoria caché del navegador móvil, Revisited

En los límites de memoria caché del navegador móvil: Android, iOS y webOS , que compartió los resultados de mis esfuerzos por determinar los límites de memoria caché del navegador de Android, iOS y dispositivos de webOS. Al final del artículo, escribí:

Utilizar estos resultados como punto de partida, pero verificar su propia cuenta antes de tomar decisiones importantes basadas en suposiciones acerca de las limitaciones caché móvil. Los cambios de navegador móvil del mundo a un ritmo relámpago, por lo que esta investigación tendrá una vida útil muy corta.

Pues resulta, que fue un buen consejo: el día después de que el artículo fue publicado, Steve Souders comentó que había corrido las pruebas con una metodología diferente que fuera más representativo de un flujo de trabajo web en el mundo real y había obtenido resultados diferentes.

Nueva Metodología

Mi metodología original involucrados navegar directamente a una página al azar generados de un cierto tamaño, se sirve con un text/html tipo de contenido. Los resultados obtenidos con esta metodología se fiable reproducible (excepto en webOS), pero como señala Steve, los usuarios no navegar directamente a los archivos CSS y JavaScript. Mi suposición de que los límites para la navegación directa a un recurso de HTML son los mismos que los límites externos de CSS y JavaScript fue incorrecta, por lo que aunque los resultados de mis pruebas eran válidas, no eran de aplicación general.

A lo largo de muchas sesiones de mensajería instantánea, correos electrónicos varios, y un par de llamadas telefónicas, Steve y yo trabajamos con una metodología de prueba nueva. He implementado una versión del mismo en la parte superior de mi marco de pruebas de memoria caché , y luego Steve implementó una versión capaz de publicar los resultados de Browserscope .

En las nuevas pruebas, se carga una página HTML que se refiere a una generada aleatoriamente CSS o JavaScript componente de un cierto tamaño. Entonces ir a una segunda página HTML que carga el mismo componente y comprueba si es o no se ha cargado desde la caché. Para determinar si un elemento se ha cargado desde la caché, se almacena una marca de tiempo en una cookie en cada solicitud, si la fecha y hora se actualiza la segunda vez que carga el componente, sabemos que la solicitud de golpear el servidor, lo que significa que el componente no se ha cargado de la caché.

Nuevos resultados

Se encontró que todos los navegadores móviles que hemos probado fueron significativamente más altos límites de caché para los recursos externos cargados por una página de lo que hizo por una página HTML. Esta es una excelente noticia para los desarrolladores web para móviles.

La siguiente tabla muestra los resultados:

Tenga en cuenta que era de 4 MB el tamaño más grande que hemos probado, y todos los componentes de los dispositivos IOS caché de 4 MB. El límite de caché real de estos dispositivos puede ser mayor que 4 MB. Además, webOS de la Palm Pre Plus dio resultados consistentes en esta prueba, mientras que había algunos problemas en la prueba anterior.

Es posible que los límites mucho más bajos de mi ensayo anterior mostró de componentes HTML de IOS pueden indicar el uso de una caché de memoria RAM para los componentes, mientras que los límites mucho más altos para CSS / JS componentes de este examen pueden indicar el uso de una caché de disco, pero esto es sólo una conjetura. Android, por lo menos, parece utilizar un caché de disco en ambos casos, ya que su caché sobrevive ciclos de energía.

Nuevas recomendaciones

En base a estos nuevos resultados, junto con los resultados de mis pruebas anteriores, les ofrezco la versión actualizada del siguiente conjunto de recomendaciones:

• El uso futuro lejano encabezados caducidad de la caché. Esto evitará que el navegador tenga que enviar una petición GET condicional.
• Trate de limitar las páginas HTML en 25.6KB o menos, si usted quiere que se almacenan en caché, ya que las pruebas anteriores mostraron que este límite impuesto por el IOS 3.2 en el IPAD, fue el más bajo límite de recursos HTML de los dispositivos probados.
• Mantenga CSS y JS componentes inferior a 1 MB. Por supuesto, 1MB es enorme y sus componentes debe ser mucho menor que esto, pero no te molestes en la división de un componente en solicitudes separadas por el bien de almacenamiento en caché a menos que su tamaño se acerca 1MB.
• Considere el uso de la caché de la aplicación HTML5 si es importante que los componentes de persistir en la memoria caché durante mucho tiempo, oa través de ciclos de energía.
• Hacer sus propios análisis. Hice hincapié en la importancia de esto en mi artículo anterior y voy a insistir de nuevo aquí. Utilizar estos resultados como punto de partida, pero verificar su propia cuenta antes de tomar decisiones importantes basadas en ellas.

Buscar conversaciones: Bloglines | technorati

Compartir y ampliar: Marcar con del.icio.us | Digg it! | reddit!