Todavía son útiles. HTTP/2 reduce el impacto de algunas de estas prácticas, pero no las elimina .

La minificación sigue siendo tan útil como siempre . Aunque HTTP/2 introduce una nueva compresión para los encabezados de los mensajes, eso no tiene nada que ver con la minificación (que se trata de los cuerpos de los mensajes). Los algoritmos de compresión para los cuerpos de los mensajes son los mismos, por lo que la minificación ahorra tanto ancho de banda como antes.

La concatenación y los sprites tendrán menos impacto que antes, pero seguirán teniendo algún impacto . El mayor problema con la descarga de varios archivos en lugar de un solo archivo con HTTP/1 no es en realidad un problema del lado HTTP per se : hay una sobrecarga basada en el ancho de banda al solicitar cada archivo individualmente, pero se ve eclipsado por el tiempo basado la sobrecarga de eliminar la sesión TCP/IP cuando haya terminado con un archivo, luego iniciar una nueva para el siguiente y repetir esto para cada archivo que desee descargar.

El enfoque más importante de HTTP/2 es eliminar esa sobrecarga basada en el tiempo: HTTP/1.1 intentó hacer esto con canalización, pero no funcionó en el navegador (Presto es el único motor que lo hizo completamente bien, y Presto es muerto). HTTP/2 es otro intento, que mejora los métodos de HTTP/1.1 al mismo tiempo que hace que este tipo de cosas no sean opcionales, y tiene más éxito. También elimina parte de la sobrecarga basada en el ancho de banda al realizar varias solicitudes, al comprimir los encabezados, pero no puede eliminar esa sobrecarga por completo, y cuando se descargan varios archivos, esas solicitudes aún deben realizarse (como parte de una única sesión TCP/IP). , por lo que hay menos gastos generales, pero no cero). Entonces, si bien el impacto de la concatenación y el spriting es proporcionalmente menor, todavía hay algún impacto, especialmente si usa muchos archivos.

Otra cosa a considerar, cuando se trata de concatenación y spriting, es la compresión. Los archivos concatenados de tipos similares tienden a comprimirse mejor que los archivos individuales , porque el algoritmo de compresión puede aprovechar las similitudes entre los datos concatenados. Un principio similar se aplica a los sprites : colocar imágenes similares en diferentes regiones del mismo archivo generalmente da como resultado un archivo más pequeño, porque la compresión de la imagen puede aprovechar las similitudes en las diferentes regiones.

Hasta ahora, todas las respuestas asumen tácitamente que querrá descargar TODOS los archivos .CSS y .JS para cada página. Una ventaja de usar http/2 y mantener separados los archivos .CSS y .JS es que solo puede eliminar los que necesita, y no descargar algo siempre es más rápido que descargarlo de manera eficiente.

Sí, sigue siendo útil.

Junto con la compresión gzip, su página pesará menos.

Imagine que está utilizando una red GPRS muy lenta (56 Kbps, 500 ms de ping).

Tienes 50 imágenes diminutas, 30 javascripts y 20 archivos css.

Esto significa que, con 2 conexiones en paralelo, debe esperar más de 100 * 500 ms solo para las solicitudes.

Ahora, cada imagen tiene alrededor de 3-4kb. Lo que podría tomar unos pocos milisegundos (¿5-8?).

Ahora, los archivos CSS y Javascript oscilan entre 20 Kb y 600 Kb.

Esto matará a su sitio web con un gran tiempo de transferencia.

Reducir el tiempo de transferencia de los archivos aumentará la "velocidad" a la que se cargará el sitio web.

Entonces, SÍ , ¡todavía es útil!