Push en HTTP2

Hoy vamos a hablar de una característica o bien poco conocida, o bien poco usada que nos llegó con la implantación del protocolo HTTP/2, que es el uso de push. La práctica totalidad de navegadores aceptan esta funcionalidad, incluyendo Internet Explorer 11, pero aún en el caso de que no fuera soportada es una característica totalmente opcional, de la que los clientes que puedan aprovecharse lo harán y los que no ni siquiera se darán cuenta.

Con todo el cambio que introdujo SPDY y posteriormente HTTP2 al pasarse a marcos binarios (en contraste con el uso anterior de texto plano), una de las mejoras introducidas fue el dar la capacidad al servidor a “empujar” contenido al navegador sin esperar a que este lo pida. La evolución del protocolo se puede ver bien en el siguiente gráfico (vía Saurabh Agarwal)

Como se puede ver, las distintas evoluciones del protocolo han permitido que cada vez nuestras conexiones sean más rápidas y eficientes. Pero, ¿qué es exactamente el push y como funciona?

Pongamos una página web normal muy básica para el ejemplo, como puede ser la portada de cualquier site. Lo habitual es que esté compuesta por un documento HTML (que llamaremos page.html), al menos una hoja de estilos (style.css) y uno o varios ficheros JS para enriquecer la web (script.js). El orden de eventos en una petición que usase HTTP/1.1 sería:

  • El cliente solicita la portada ( GET /page.html)
  • El servidor le devuelve la portada
  • El cliente examina la portada, parseando el código HTML
  • El cliente pide la hoja de estilos (GET /style.css)
  • El servidor le devuelve la hoja de estilos
  • El cliente pide el js (GET /script.js)
  • El servidor le devuelve el js.
  • El cliente aplica los estilos y el js en el navegador para que la página se muestre completa.

En HTTP/2 con PUSH el flujo sería este:

  • El cliente solicita la portada ( GET /page.html)
  • El servidor le devuelve la portada
  • El servidor, con HTTP2 push activado, examina las cabeceras Link, y se da cuenta que tiene que empujar también style.css script.js, y aprovecha la misma conexión para enviarlos.
  • El cliente examina la portada, parseando el código HTML.
  • El cliente encuentra que tendría que pedir la hoja de estilos, pero ya la tiene. No se hace petición.
  • El cliente encuentra que tendría que pedir el JS, pero ya lo tiene. No se hace petición.
  • El cliente aplica los estilos y el js en el navegador para que la página se muestre completa.

De forma más gráfica:

El servidor inicia transmisiones (promesas) nuevas para recursos push:

Un ejemplo práctico puede verse en la web de Transparent CDN, que precarga varias hojas de estilo usando una cabecera “link” en la respuesta:

link: </wp-includes/css/dist/block-library/style.min.css?ver=5.2.4>; rel=preload; as=style, </wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.1.4>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-public.css?ver=1.8.1>; rel=preload; as=style, </wp-content/plugins/cookie-law-info/public/css/cookie-law-info-gdpr.css?ver=1.8.1>; rel=preload; as=style

Esto se puede ver reflejado en las herramientas del navegador al cargar la página, bajo la columna «Initiator»:


Huelga decir que todas las capacidades que provee HTTP/2 están completamente soportadas en Transparent CDN, donde ya estamos jugando con HTTP/3. ¿Y tú? ¿Aún sigues con el gif de «under construction» del año 95? Hazte cliente!

Connection, accepted.