Chrome tiene la intención de eliminar la compatibilidad con Server Push

Los desarrolladores de Chrome, dieron a conocer que tienen la intención de dejar de admitir el mecanismo Server Push en los protocolos HTTP/2 y gQUIC, así como no implementarlo para el protocolo HTTP/3, que se encuentra en la etapa de aprobación estándar. La tecnología Server Push no se proporciona en el protocolo HTTP/1.1 desde el principio.

El motivo de la eliminación es el deseo de deshacerse de una gran complicación en el código, en el contexto de la falta de demanda y solo requisitos previos teóricos para la efectividad de las optimizaciones basadas en Server Push.

La tecnología Server Push se define en el estándar HTTP/2 y tiene como objetivo optimizar la carga de datos.

Además de los navegadores basados ​​en el motor Chromium, la compatibilidad con Server Push se implementa actualmente en Firefox y Safari, y en el lado del servidor en nginx y Apache httpd.

Con Server Push, el servidor puede enviar recursos al cliente sin esperar su solicitud explícita. Se asume que de esta manera el servidor puede acelerar la carga de la página, ya que los archivos CSS, scripts e imágenes necesarios para renderizar la página ya estarán transferidos a su lado cuando el cliente lo solicite.

El cliente se conecta y solicita una página específica, luego de lo cual el servidor, con base en su configuración o al contenido del encabezado del Link enviado por el cliente, inicia la transferencia de ciertos recursos a través de la conexión HTTP/2 ya establecida, sin esperar la solicitud de estos recursos por parte del cliente.

El contenido transferido a través de la llamada push se almacena en el lado del cliente en un caché especial asociado con la conexión HTTP/2 actual.

Cuando, en el proceso de procesamiento de una página, el cliente llega a la solicitud de los recursos asociados a ella (css, js, imágenes, etc.), se realiza una verificación en la caché antes de enviar realmente cada solicitud. Si el recurso ya ha sido transferido por el servidor y está en la caché, el cliente descarga este recurso de la caché local sin realizar una solicitud externa al servidor.

HTTP / 3 es un protocolo casi RFC que también define la inserción del servidor.

Actualmente, Chrome admite el manejo de transmisiones push a través de HTTP/2 y gQUIC, y esta intención consiste en eliminar la compatibilidad con ambos protocolos. Chrome no admite la inserción a través de HTTP/3 y agregar compatibilidad no está en la hoja de ruta.

El mantenimiento de dicha caché complica enormemente la implementación de Server Push en el lado del cliente, pero no conduce a una notable aceleración de la carga en comparación con la solicitud preventiva de recursos a través de la etiqueta «preload» y, según algunos estudios, incluso aumenta la latencia.

Según las estadísticas de Google, la tecnología Server Push no ha recibido una distribución adecuada. Por ejemplo, en los últimos 28 días, el 99,95% de las conexiones HTTP/2 no utilizaron Server Push. Se observaron indicadores similares durante el estudio en junio de 2019, es decir, no hay crecimiento en las implementaciones de Server Push.

Además, este año, solo el 40% de los mensajes recibidos por Server Push fueron utilizados por el navegador, y hace dos años esta cifra era del 63,51% (los mensajes sin procesar eran incorrectos, no coincidían con la página procesada o ya estaban en la caché).

En lugar de Server Push, para optimizar la carga de la página, se propone utilizar la etiqueta <link rel = «preload»>, en función de la cual el navegador puede solicitar un recurso sin esperar su uso en la página.

Por un lado, la precarga, en comparación con Server Push, conduce a un intercambio de paquetes innecesario (RTT), pero por otro lado, evita el envío de recursos que ya están en la caché del navegador.

En general, las diferencias de latencia cuando se usa Server Push y preload se consideran insignificantes. Además de optimizar la carga de recursos, el mecanismo Server Push también se puede utilizar para transmitir datos desde el servidor al cliente, pero el protocolo WebTransport (basado en QUIC) es más adecuado para este propósito, cuya estandarización se encuentra en la etapa de borrador.

Fuente:https://groups.google.com