performance - Optimización del almacenamiento en caché de archivos y HTTP2

browser-cache pagespeed

Question

Nuestro sitio está considerando hacer el cambio a http2.

Tengo entendido que http2 hace que las técnicas de optimización como la concatenación de archivos sean obsoletas , ya que un servidor que usa http2 solo envía una solicitud.

En cambio, el consejo que estoy viendo es que es mejor mantener los tamaños de archivo más pequeños para que sea más probable que un navegador los almacene en caché.

Probablemente depende del tamaño de un sitio web, pero ¿qué tan pequeños deben ser los archivos de un sitio web si usa http2 y quiere centrarse en el almacenamiento en caché?

En nuestro caso, nuestros muchos archivos js y css individuales caen en el rango de 1 kb a 180 kb. Jquery y bootstrap podrían ser más. Acumulativamente, una descarga nueva de una página en nuestro sitio suele ser inferior a 900 kb.

Entonces tengo dos preguntas:

¿Son estos tamaños de archivo lo suficientemente pequeños para que los navegadores los almacenen en caché?

Si son lo suficientemente pequeños como para ser almacenados en caché, de todos modos es bueno concatenar archivos para usuarios que usan navegadores que no admiten http2.

¿Le dolería tener archivos de mayor tamaño en este caso Y usar HTTP2? De esta manera, beneficiaría a los usuarios que ejecutan cualquiera de los protocolos porque un sitio podría optimizarse tanto para http como para http2.

Answer 1

Aclaremos algunas cosas:

Tengo entendido que http2 hace que las técnicas de optimización como la concatenación de archivos sean obsoletas, ya que un servidor que usa http2 solo envía una solicitud.

HTTP / 2 hace que las técnicas de optimización, como la concatenación de archivos, sean algo obsoletas, ya que HTTP / 2 permite que muchos archivos se descarguen en paralelo a través de la misma conexión. Anteriormente, en HTTP / 1.1, el navegador podía solicitar un archivo y luego tenía que esperar hasta que el archivo se descargara completamente antes de poder solicitar el siguiente archivo. Esto lleva a soluciones como la concatenación de archivos (para reducir la cantidad de archivos necesarios) y múltiples conexiones (un truco para permitir descargas en paralelo).

Sin embargo, hay un argumento en contra de que todavía hay gastos generales con varios archivos, incluidos solicitarlos, almacenarlos en caché, leerlos desde la caché ... etc. Se reduce mucho en HTTP / 2 pero no se ha eliminado por completo. Además, comprimir archivos de texto funciona mejor en archivos más grandes, que comprimir muchos archivos más pequeños por separado. Personalmente, sin embargo, creo que las desventajas superan estas preocupaciones, y creo que la concatenación desaparecerá una vez que HTTP / 2 sea omnipresente.

En cambio, el consejo que estoy viendo es que es mejor mantener los tamaños de archivo más pequeños para que sea más probable que un navegador los almacene en caché.

Probablemente depende del tamaño de un sitio web, pero ¿qué tan pequeños deben ser los archivos de un sitio web si usa http2 y quiere centrarse en el almacenamiento en caché?

El tamaño del archivo no tiene relación con si se almacenará en caché o no (a menos que estemos hablando de archivos verdaderamente masivos más grandes que el caché en sí). La razón por la que dividir los archivos en fragmentos más pequeños es mejor para el almacenamiento en caché es que si realiza algún cambio, los archivos que no se hayan tocado aún se pueden usar desde el caché. Si tiene todos sus javascript (por ejemplo) en un gran archivo .js y cambia una línea de código, entonces todo el archivo debe descargarse nuevamente, incluso si ya estaba en el caché.

Del mismo modo, si tiene un mapa de sprites de imágenes, eso es excelente para reducir las descargas de imágenes separadas en HTTP / 1.1, pero requiere que todo el archivo de sprites se descargue nuevamente si alguna vez necesita editarlo para agregar una imagen adicional, por ejemplo. Sin mencionar que todo se descarga, incluso para páginas que solo usan uno de esos sprites de imágenes.

Sin embargo, dicho todo eso, hay un tren de pensamiento que dice que el beneficio del almacenamiento en caché a largo plazo se ha exagerado. Consulte este artículo y, en particular, la sección sobre el almacenamiento en caché HTTP que muestra que la memoria caché del navegador de la mayoría de las personas es más pequeña de lo que cree, por lo que es poco probable que sus recursos se almacenen en la memoria caché durante mucho tiempo. Eso no quiere decir que el almacenamiento en caché no sea importante, pero es más útil para navegar en esa sesión en lugar de a largo plazo. Por lo tanto, es probable que cada visita a su sitio descargue todos sus archivos nuevamente, a menos que sean visitantes frecuentes, tengan un caché muy grande o no naveguen mucho por la web.

¿es bueno concatenar archivos de todos modos para usuarios que usan navegadores que no admiten http2?

Posiblemente. Sin embargo, aparte de en Android, el soporte del navegador HTTP / 2 es realmente muy bueno, por lo que es probable que la mayoría de sus visitantes ya estén habilitados para HTTP / 2.

Dicho esto, no hay inconvenientes adicionales para concatenar archivos bajo HTTP / 2 que no estaban allí bajo HTTP / 1.1. Bien, se podría argumentar que se pueden descargar varios archivos pequeños en paralelo a través de HTTP / 2, mientras que un archivo más grande debe descargarse como una solicitud, pero no creo que eso lo ralentice mucho. No hay prueba de esto, pero la intuición sugiere que los datos aún deben enviarse, por lo que tiene un problema de ancho de banda de cualquier manera, o no. Además, la sobrecarga de solicitar muchos recursos, aunque todavía se reduce mucho en HTTP / 2. La latencia sigue siendo el mayor problema para la mayoría de los usuarios y sitios, no para el ancho de banda. A menos que sus recursos sean realmente enormes, dudo que note la diferencia entre descargar 1 gran recurso en I go, o los mismos datos divididos en 10 pequeños archivos descargados en paralelo en HTTP / 2 (aunque lo haría en HTTP / 1.1) . Sin mencionar los problemas de gzipping discutidos anteriormente.

Entonces, en mi opinión, no hay daño en seguir concatenando por un tiempo más. En algún momento, deberá decidir si las desventajas son mayores que los beneficios dados a su perfil de usuario.

¿Le dolería tener archivos de mayor tamaño en este caso Y usar HTTP2? De esta manera, beneficiaría a los usuarios que ejecutan cualquiera de los protocolos porque un sitio podría optimizarse tanto para http como para http2.

Absolutamente no dolería en absoluto. Como se mencionó anteriormente, (básicamente) no hay inconvenientes adicionales para concatenar archivos bajo HTTP / 2 que no estaban allí bajo HTTP / 1.1. Simplemente ya no es necesario en HTTP / 2 y tiene inconvenientes (potencialmente reduce el uso del almacenamiento en caché, requiere un paso de compilación, hace que la depuración sea más difícil ya que el código implementado no es lo mismo que el código fuente ... etc.).

Use HTTP / 2 y aún verá grandes beneficios para cualquier sitio, excepto los sitios más simples que probablemente no verán ninguna mejora, pero tampoco negativos. Y, como los navegadores más antiguos pueden seguir con HTTP / 1.1, no hay inconvenientes para ellos. Cuando, o si, decide dejar de implementar ajustes de rendimiento HTTP / 1.1 como la concatenación es una decisión separada.

De hecho, la única razón para no usar HTTP / 2 es que las implementaciones todavía son bastante innovadoras, por lo que es posible que todavía no se sienta cómodo al ejecutar su sitio web de producción.

**** Editar agosto de 2016 ****

Esta publicación de un sitio de imagen de gran ancho de banda ha despertado interés en la comunidad HTTP / 2 como uno de los primeros ejemplos documentados de donde HTTP / 2 era realmente más lento que HTTP / 1.1. Esto resalta el hecho de que la tecnología HTTP / 2 y la comprensión aún son nuevas y requerirán algunos ajustes para algunos sitios. ¡Parece que no hay un almuerzo gratis! Vale la pena leerlo, aunque vale la pena tener en cuenta que este es un ejemplo extremo y que la mayoría de los sitios están mucho más afectados, en términos de rendimiento, por problemas de latencia y limitaciones de conexión bajo HTTP / 1.1 en lugar de problemas de ancho de banda.