Optimización de caché de archivos y HTTP2

Nuestro sitio está considerando hacer el cambio a http2.

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

En cambio, el consejo que estoy viendo es que es mejor reducir el tamaño de los archivos para que el navegador los guarde en la memoria caché.

Probablemente depende del tamaño de un sitio web, pero ¿cuán 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 1kb a 180kb. Jquery y bootstrap podrían ser más. Acumulativamente, una nueva descarga de una página en nuestro sitio suele ser inferior a 900 kb.

Entonces tengo dos preguntas:

¿Son estos archivos lo suficientemente pequeños como para que los navegadores los guarden en caché?

Si son lo suficientemente pequeños como para almacenarse en caché, es bueno concatenar archivos de todos modos para los usuarios que usan navegadores que no son compatibles con http2.

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

Vamos a aclarar algunas cosas:

Tengo entendido que http2 vuelve obsoletas las técnicas de optimización, como la concatenación de archivos, 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 ese archivo estuviera completamente descargado antes de poder solicitar el siguiente archivo. Esto da lugar a soluciones como la concatenación de archivos (para reducir la cantidad de archivos necesarios) y las conexiones múltiples (un truco para permitir descargas en paralelo).

Sin embargo, existe un argumento en contra que todavía hay gastos generales con múltiples archivos, que incluyen solicitarlos, almacenarlos en caché, leerlos desde el caché … etc. Se ha reducido mucho en HTTP / 2 pero no ha desaparecido por completo. Además, los archivos de texto comprimidos gzip funcionan mejor en archivos de mayor tamaño que el de descomprimir 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 reducir el tamaño de los archivos para que el navegador los guarde en la memoria caché.

Probablemente depende del tamaño de un sitio web, pero ¿cuán 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 influye en si se almacenará en caché o no (a menos que hablemos de archivos verdaderamente masivos que el caché mismo). El motivo por el que se dividen los archivos en fragmentos más pequeños es mejor para el almacenamiento en caché, por lo que si realiza algún cambio, los archivos que aún no se hayan tocado aún podrán utilizarse desde el caché. Si tiene toda su javascript (por ejemplo) en un gran archivo .js y cambia una línea de código, entonces todo el archivo debe ser descargado nuevamente, incluso si ya estaba en la caché.

De manera similar, si tiene un mapa de sprites de imagen, eso es ideal para reducir las descargas de imágenes por separado en HTTP / 1.1, pero requiere que el archivo sprite completo se descargue nuevamente si alguna vez necesita editarlo para agregar una imagen extra, por ejemplo. Sin mencionar que todo está descargado, incluso para páginas que solo usan uno de esos sprites de imagen.

Sin embargo, al decir todo eso, hay una stream de pensamiento que dice que el beneficio del almacenamiento en caché a largo plazo está por encima de lo establecido. Consulte este artículo y, en particular, la sección sobre el almacenamiento en caché de HTTP que muestra que la 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 caché durante mucho tiempo. Eso no quiere decir que el almacenamiento en caché no es importante, pero es más útil para explorar en esa sesión que a largo plazo. Por lo tanto, cada visita a su sitio probablemente descargue todos sus archivos nuevamente, a menos que sea un visitante frecuente, tenga un caché muy grande o no navegue mucho por la web.

¿es bueno concatenar archivos de todos modos para los usuarios que utilizan navegadores que no son compatibles con http2.

Posiblemente. Sin embargo, salvo en Android, la compatibilidad con el navegador HTTP / 2 es realmente muy buena, 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 en HTTP / 2 que ya no estaban en HTTP / 1.1. Ok, podría argumentarse que se podrían descargar varios archivos pequeños en paralelo a través de HTTP / 2, mientras que un archivo más grande debe descargarse como una sola solicitud, pero no creo que eso lo ralentice mucho. No hay pruebas 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 muy reducida en HTTP / 2, todavía está allí. 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 tus recursos sean realmente enormes, dudo que notes la diferencia entre descargar 1 gran recurso en I’ve go, o los mismos datos divididos en 10 pequeños archivos descargados en paralelo en HTTP / 2 (aunque lo harías en HTTP / 1.1) . Sin mencionar los problemas de gzipping discutidos anteriormente.

Por lo tanto, en mi opinión, no hay daño para mantener la concatenación durante un poco más de tiempo. En algún momento tendrá que hacer una llamada para ver si las desventajas superan los beneficios dados a su perfil de usuario.

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

Absolutamente no duele en absoluto. Como se mencionó anteriormente, (básicamente) no hay inconvenientes adicionales para concatenar archivos en HTTP / 2 que ya no estaban en HTTP / 1.1. Ya no es tan necesario en HTTP / 2 y tiene desventajas (potencialmente reduce el uso del almacenamiento en caché, requiere un paso de comstackción, hace que la depuración sea más difícil ya que el código implementado no es el 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 vean ninguna mejora, pero tampoco negativos. Y, como los navegadores más antiguos pueden quedarse con HTTP / 1.1, no hay inconvenientes para ellos. Cuando, o si, decide dejar de implementar ajustes de rendimiento de HTTP / 1.1 como concatenar es una decisión separada.

De hecho, la única razón para no usar HTTP / 2 es que las implementaciones aún están bastante desangradas, por lo que es posible que aún no se sienta cómodo ejecutando su sitio web de producción.

**** Edición agosto 2016 ****

Esta publicación de un sitio de imágenes pesadas, vinculadas al ancho de banda, ha causado recientemente cierto interés en la comunidad HTTP / 2 como uno de los primeros ejemplos documentados de que HTTP / 2 era realmente más lento que HTTP / 1.1. Esto resalta el hecho de que la tecnología HTTP / 2 y su comprensión aún son nuevos y requerirá algunos ajustes para algunos sitios. ¡No existe tal cosa como un almuerzo gratis! Bien vale la pena leerlo, aunque vale la pena tener en cuenta que este es un ejemplo extremo y la mayoría de los sitios son mucho más afectados, en cuanto al rendimiento, por problemas de latencia y limitaciones de conexión en HTTP / 1.1 que por problemas de ancho de banda.