bundling and minification - mvc - ¿Por qué las optimizaciones de paquetes ya no son una preocupación en HTTP/2?

bundles asp net mvc 4

Question

Leí en partes de la documentación de systemjs que las optimizaciones de paquetes ya no son necesarias en HTTP / 2 :

En HTTP / 2, este enfoque puede ser preferible ya que permite que los archivos se almacenen en caché individualmente en el navegador, lo que significa que las optimizaciones de paquetes ya no son una preocupación.

Mis preguntas:

1. ¿Significa que no necesitamos pensar en empaquetar scripts u otros recursos cuando usamos HTTP / 2?
2. ¿Qué hay en HTTP / 2 que habilita esta característica?

Answer 1

El agrupamiento sigue siendo útil si su sitio web es

1. Servido en HTTP (HTTP 2.0 requiere HTTPS )
2. Alojado por un servidor que no admite ALPN y HTTP 2 .
3. Requerido para soportar navegadores antiguos (sistemas sensibles y heredados)
4. Requerido para soportar tanto HTTP 1 como 2 (degradación agraciada)

Hay dos características de HTTP 2.0 que hacen obsoleto el agrupamiento:

1. Multiplexing y concurrencia de HTTP 2.0 (permite solicitar múltiples recursos en una única conexión TCP)
2. HTTP 2.0 Server Push (Server push permite que el servidor empuje preventivamente las respuestas que cree que el cliente necesitará en la memoria caché del cliente)

PS: Bundling no es la única técnica de optimización que se eliminaría por la insurgencia de las características de HTTP 2.0. Se verán afectadas características como el spriting de imágenes , la fragmentación de dominios y la incorporación de recursos (incrustación de imágenes a través de URI de datos).

Cómo afecta HTTP 2.0 a las técnicas de optimización web existentes

Answer 2

El empaquetado está haciendo mucho en una compilación moderna de JavaScript. HTTP / 2 solo aborda la optimización de minimizar la cantidad de solicitudes entre el cliente y el servidor haciendo que el costo de las solicitudes adicionales sea mucho más barato que con HTTP / 1

Pero agrupar hoy no solo consiste en minimizar el recuento de solicitudes entre el cliente y el servidor. Otros dos aspectos relevantes son:

• Agitación de árboles : los paquetes modernos como WebPack y Rollup pueden eliminar el código no utilizado (incluso de bibliotecas de terceros).
• Compresión: los paquetes de JavaScript más grandes se pueden comprimir mejor (gzip, zopfli ...)

Además, el empuje del servidor HTTP / 2 puede desperdiciar el ancho de banda al empujar recursos que el navegador no necesita, porque todavía los tiene en el caché.

Dos buenas publicaciones sobre el tema son:

• http://engineering.khanacademy.org/posts/js-packaging-http2.htm
• https://www.contentful.com/blog/2017/04/04/es6-modules-support-lands-in-browsers-is-it-time-to-rethink-bundling/

Ambas publicaciones llegan a la conclusión de que "los procesos de construcción están aquí para quedarse".

Answer 3

HTTP / 2 admite el "empuje del servidor" que obsoleta el agrupamiento de recursos. Entonces, sí, si está utilizando HTTP / 2, el agrupamiento sería en realidad un antipatrón.

Para obtener más información, consulte esto: https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/

Answer 4

La optimización de paquetes se introdujo como una "mejor práctica" cuando se usa HTTP / 1.1 porque los navegadores solo podían abrir un número limitado de conexiones a un dominio en particular.

Una página web típica tiene más de 30 recursos para descargar para poder renderizar. Con HTTP / 1.1, un navegador abre 6 conexiones al servidor, solicita 6 recursos en paralelo, espera a que se descarguen, luego solicita otros 6 recursos, etc. (o por supuesto, algunos recursos se descargarán más rápido que otros y esa conexión podría reutilizarse antes que otros para otra solicitud). El punto es que con HTTP / 1.1 solo puede tener como máximo 6 solicitudes pendientes.

Para descargar 30 recursos, necesitarías 5 viajes de ida y vuelta, lo que agrega mucha latencia a la representación de la página.

Para hacer que la página sea más rápida, con HTTP / 1.1, el desarrollador de la aplicación tuvo que reducir el número de solicitudes para una sola página. Esto dio lugar a "mejores prácticas", como la fragmentación de dominios, la incorporación de recursos, el spriting de imágenes, el agrupamiento de recursos, etc., pero en realidad son solo hacks inteligentes para solucionar las limitaciones del protocolo HTTP / 1.1.

Con HTTP / 2 las cosas son diferentes porque HTTP / 2 es multiplexado. Incluso sin HTTP / 2 Push, la función de multiplexación de HTTP / 2 hace que todos esos hacks sean inútiles, porque ahora puede solicitar cientos de recursos en paralelo usando una sola conexión TCP.

Con HTTP / 2, los mismos 30 recursos requerirían solo 1 viaje de ida y vuelta para descargar, lo que le otorga un aumento de rendimiento 5x directo en esa operación (que generalmente domina el tiempo de representación de la página).

Dado que la tendencia del contenido web es ser más rica, tendrá más recursos; Cuantos más recursos, mejor rendimiento de HTTP / 2 con respecto a HTTP / 1.1.

Además de la multiplexación de HTTP / 2, tiene HTTP / 2 Push.

Sin HTTP / 2 Push, el navegador debe solicitar el recurso principal (la página * .html), descargarlo, analizarlo y luego organizar la descarga de los 30 recursos a los que hace referencia el recurso principal.

HTTP / 2 Push le permite obtener los 30 recursos mientras solicita el recurso principal que los referencia, ahorrando un viaje de ida y vuelta más, de nuevo gracias a la multiplexación de HTTP / 2.

En realidad, es la característica de multiplexación de HTTP / 2 que le permite olvidarse del agrupamiento de recursos.

Puede ver las slides de la sesión HTTP / 2 que di en varias conferencias.