Resumen

  • El RFC 7540 autorizó al servidor HTTP/2 a prometer y enviar un recurso antes de que el cliente lo solicitara. El navegador podía desactivar o rechazar la propuesta.
  • El RFC 9113 mantuvo la función en junio de 2022 y explicó por qué los errores de predicción consumen capacidad. La nota de Chrome 106 confirmó la eliminación de la recepción y uso de flujos enviados por el servidor.

Una predicción viaja por la conexión

Una página HTML puede anunciar una hoja de estilo. El servidor la conoce antes de que el navegador termine de leer el documento. La idea de Server Push era sencilla: enviarla ya y ahorrar el viaje de ida y vuelta de una petición posterior. El HTTP/2 publicado en 2015 plasmó la idea en PUSH_PROMISE. El servidor fabricaba una petición probable en nombre del cliente y entregaba la respuesta por otro flujo.

El mecanismo tenía límites. La promesa debía acompañar a una solicitud real del navegador; el recurso tenía que poder almacenarse en caché y respetar las reglas de autoridad del servidor. El cliente podía fijar SETTINGS_ENABLE_PUSH=0 o cancelar un flujo que no quería. La norma permitía que el servidor adivinara. No convertía su adivinanza en una necesidad del navegador.

La información decisiva estaba dividida. El servidor veía la página que iba a servir. El navegador sabía si conservaba la hoja de estilo en caché, qué versión aceptaba y qué otros recursos necesitaba antes. Si el servidor enviaba lo que el navegador ya tenía, esos bytes ocupaban la conexión y podían retrasar la respuesta importante. El ahorro de un viaje dependía de acertar el destino y el momento.

La norma conserva la función y señala la factura

El RFC 9113 de junio de 2022 todavía dedicaba una sección a Server Push. Describía el beneficio posible para estilos y scripts que el navegador pediría enseguida. También decía por qué era difícil conseguirlo: caché, negociación de contenido y conducta del usuario complicaban la previsión. Una respuesta enviada por error podía competir con otra más urgente y empeorar el rendimiento. El cliente conservaba su ajuste para desactivar el envío.

En agosto, Chrome anunció que desactivaría Server Push por defecto en la versión 106. Habló de ganancias difíciles de obtener y de resultados mixtos, incluso retrocesos. La relación de cambios de Chrome 106 fue más concreta: desaparecía la capacidad de recibir, mantener en memoria y utilizar los flujos HTTP/2 empujados por el servidor. El texto de la norma seguía ahí; el producto que abre la página dejó de hacer el trabajo de recibir.

La secuencia tiene una ironía técnica. La revisión de HTTP/2 había explicado precisamente el problema que Chrome usó al retirar el soporte. El organismo de normalización conservó la opción y sus reglas; el equipo del navegador decidió que administrar el paquete especulativo ya no compensaba. Una función puede estar perfectamente definida y perder su lugar en el programa que usa la gente.

Pistas en vez de respuestas adelantadas

La explicación de Chrome señaló 103 Early Hints y la precarga como otros caminos para empezar antes. Una pista avisa de un recurso probable; el navegador decide si solicita el archivo, teniendo en cuenta su caché. La sustitución importa aquí por lo que revela sobre Server Push: la respuesta completa llegaba por iniciativa del servidor, y su recepción tenía un coste aunque el navegador no la necesitara.

HTTP/2 siguió funcionando. El RFC siguió describiendo Server Push. Chrome 106 dejó de recibir sus flujos. La historia cabe en esa diferencia entre permiso escrito y trabajo ejecutado.