Quitar el servidor HTTP/2 push de Chrome

Siguiendo con el anuncio anterior, la compatibilidad con la extracción de servidor HTTP/2 se inhabilitará de forma predeterminada en Chrome 106 y otros navegadores basados en Chromium en sus próximas versiones.

¿Por qué se quitará?

El envío del servidor HTTP/2 permitió que los sitios web enviaran de forma proactiva los recursos que necesitaba la página en lugar de esperar a que se solicitaran. Sin embargo, como escribió Jake Archibald anteriormente, era problemático, y los beneficios de rendimiento a menudo eran difíciles de obtener. Como resultado, no se usó mucho, ya que solo el 1.25% de los sitios HTTP/2 utilizaban esta función.

El análisis del uso de HTTP/2 Server Push tiene resultados mixtos (Chrome, Akamai), sin una ganancia neta de rendimiento clara y, en muchos casos, regresiones de rendimiento.

El envío no se implementó en muchos servidores y clientes HTTP/3, a pesar de que se incluyó en la especificación. En gran parte de la Web que usa el HTTP/3 más reciente, el envío ya se retiró. Cuando volvimos a ejecutar ese análisis más recientemente, observamos que la compatibilidad con HTTP/2 de los sitios pasó del 1.25% al 0.7%.

Alternativas a la transmisión del servidor HTTP/2

Las sugerencias anticipadas de 103 son una alternativa mucho menos propensa a errores con muchas de las mismas ventajas que Push y muchas menos desventajas. En lugar de que el servidor envíe recursos, las sugerencias anticipadas de 103 solo envían sugerencias al navegador de recursos que podría beneficiarse de solicitar de inmediato. De esta manera, el navegador puede decidir si los necesita o no, por ejemplo, si ya tiene esos recursos en la caché HTTP.

La precarga de recursos críticos es otra alternativa que permite que la página y el navegador trabajen juntos para cargar recursos críticos de forma preventiva al principio de la carga de la página. Si bien esto requiere que se envíe primero la página en sí (por lo que no es tan rápido como el envío del servidor ni los indicadores anticipados), tiene el beneficio adicional de no retrasar ese recurso de página crítico, lo que puede suceder con ambas soluciones.

Conclusión

La Web debe poder probar elementos y descartarlos cuando no se usen. Aunque el potencial de Push sonaba bien, en realidad, usarlo era más problemático de lo previsto. Sin embargo, aprendimos mucho de Push, que se incorporó al diseño de 103 Early Hints. Ahora es momento de completar la progresión y alejarse de Push.

Recursos