Yahoo! Blog User Interface (YUIBlog)

Limites do navegador Mobile Cache, revisitado

Em Limites navegador Mobile Cache: Android, iOS, e webOS , eu compartilhei os resultados de minhas tentativas de determinar limites de cache do navegador no Android, IOS e dispositivos webOS. No final do artigo, escrevi:

Use estes resultados como um ponto de partida, mas verificá-los você mesmo antes de tomar decisões importantes baseadas em suposições sobre as limitações de cache móveis. As mudanças de navegador móvel do mundo em um ritmo relâmpago, por isso esta investigação terá uma vida útil muito curta.

Como se vê, que foi um bom conselho: no dia seguinte o artigo foi publicado, Steve Souders comentou que ele tinha executar testes usando uma metodologia diferente, que era mais representativo de um fluxo de trabalho web no mundo real e tinha obtido resultados diferentes.

Nova Metodologia

Minha metodologia original envolvida navegar diretamente para uma página gerada aleatoriamente de um certo tamanho, servido com um text/html tipo de conteúdo. Os resultados utilizando esta metodologia foi reprodutível confiável (exceto no webOS), mas como Steve apontou, os usuários não navegar diretamente para arquivos CSS e JavaScript. Minha suposição de que os limites para a navegação directa a um recurso HTML foram os mesmos que os limites para CSS externa e JavaScript estava errada, por isso mesmo que os resultados dos meus testes eram válidas, não eram amplamente aplicáveis.

Ao longo das sessões de mensagens instantâneas, e-mails muitos diversos, e um par de telefonemas, Steve e eu trabalhei uma metodologia de teste de novo. Eu implementei uma versão dele em cima da minha framework de testes de cache , em seguida, Steve implementou uma versão capaz de publicar resultados de Browserscope .

Nos novos testes, nós carregamos uma página HTML que se refere a um CSS gerado aleatoriamente ou componente JavaScript de um certo tamanho. Em seguida, navegar para uma segunda página HTML que carrega o mesmo componente e verifica se ele estava ou não carregados a partir do cache. Para determinar se um componente foi carregado a partir do cache, que armazena um timestamp em um cookie em cada pedido, se a hora é atualizada a segunda vez que carregar o componente, sabemos que o pedido de bater o servidor, o que significa que o componente não foi carregado a partir do cache.

Novos resultados

Descobrimos que todos os navegadores móveis que testamos tinha limites de cache significativamente mais elevados de recursos externos carregados por uma página do que eles fizeram para uma página HTML em si. Esta é uma excelente notícia para os desenvolvedores da web móvel.

A tabela abaixo ilustra os nossos achados:

Note-se que 4MB era o maior tamanho que testado, e todos os dispositivos iOS componentes 4MB cache. O limite de cache real desses dispositivos pode ser maior que 4MB. Além disso, webOS sobre o Palm Pre Além disso, deu resultados consistentes neste teste, mas teve alguns problemas no teste anterior.

É possível que os limites muito mais baixos meu teste anterior mostrou para componentes HTML no IOS pode indicar o uso de um cache de RAM para os componentes, enquanto que os limites muito mais elevados para CSS / JS componentes neste teste pode indicar a utilização de um cache de disco, mas isso é apenas conjectura. Android, pelo menos, parece utilizar um cache de disco em ambos os casos, uma vez que o seu cache sobrevive ciclos de potência.

Novas Recomendações

Com base nesses resultados novos, juntamente com os resultados dos meus testes anteriores, eu ofereço o seguinte conjunto de recomendações atualizadas:

• Use far-futuros cabeçalhos de expiração de cache. Isto irá evitar que o navegador de ter que enviar um pedido de condicional GET.
• Tente limitar páginas HTML para 25.6KB ou menos, se você quer que eles sejam armazenados em cache, uma vez que os testes anteriores mostraram que esse limite imposto pelo iOS 3.2 no iPad, era o limite mais baixo de recursos HTML dos dispositivos testados.
• Mantenha os componentes CSS e JS em 1MB. Claro, 1MB é enorme e seus componentes devem ser muito menor do que isso, mas não se incomode um componente dividindo-se em pedidos separados para o bem da cacheability a menos que seu tamanho se aproxima de 1MB.
• Considere o uso de cache do aplicativo HTML5 se é importante que os seus componentes persistem no cache por um longo tempo, ou através de ciclos de energia.
• Faça seus próprios testes. Eu salientou a importância deste no meu artigo anterior e eu vou forçá-lo novamente aqui. Use estes resultados como um ponto de partida, mas verificá-los você mesmo antes de tomar decisões importantes com base nelas.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!