HTTP/2 y HTTP/3: ¿Qué es y cómo mejora la velocidad de tu página?

Hoy por hoy, hablar de HTTP2 y HTTP3 es algo ya normal, es más, incluso ha dejado de ser una novedad a pesar de que HTTP/3 es bastante reciente.

En el momento de publicar este artículo, HTTP 2 tiene una cuota de mercado del 46,3% que sube lentamente, mientras que HTTP 3 tiene una cuota de mercado del 25% que aumenta rápidamente cada mes. Los principales servicios de CDN son compatibles con los nuevos protocolos HTTP, como HTTP2 y HTTP 3, desde el principio. Eso es algo que suele "empujar" las cuotas de mercado hacia arriba los primeros años de implementación de una nueva versión: https://w3techs.com/technologies/details/ce-http3 Desde el año 1999 hasta el año 2015 hemos estado con el protocolo HTTP1.1 y, en cuestión de pocos años, se han hecho mejoras importantes en el protocolo HTTP, sobre todo para incrementar la eficiencia de la conexión entre el cliente (navegador web) y el servidor (hosting). Cuando HTTP 1.1 era lo común, teníamos que utilizar técnicas WPO como el domain sharding para paralelizar las cargas. También era habitual combinar varios archivos del mismo tipo en uno solo para ahorrar peticiones HTTP. Ahora, con HTTP 2, ninguna de estas dos cosas son necesarias y, de hecho, si las aplicamos pueden ser contraproducentes. Antes de empezar a explicar cosas sobre HTTP2 y HTTP3, vamos a hablar de lo que es HTTP y de cómo ha acompañado al crecimiento de Internet desde el año 1996, cuando apareció HTTP 0.9. [elementor-template id="80835"]

¿Qué es el protocolo HTTP?

Podemos definir HTTP como un lenguaje que se encarga de hacer de intermediario entre las peticiones de un cliente (navegador web del usuario) y las respuestas de un servidor (hosting que aloja el sitio web). HTTP son las siglas de "Protocolo de Transferencia de Hipertexto" o "Hypertext Transfer Protocol". En todo caso, siempre se le llama HTTP y es muy raro que se utilice el nombre completo. Como he comentado antes, estuvimos unos cuantos años con HTTP 1 y en 2015 "se pusieron a trabajar" y sacaron dos versiones "potentes" en cuestión de pocos años. El protocolo HTTP es la base de Internet, ya que es el sustento de la web y de la comunicación entre el cliente y el alojamiento web. El mantenimiento del protocolo y las nuevas versiones del protocolo HTTP son desarrolladas por la IETF (Internet Engineering Task Force), una organización internacional abierta que se encarga de la mejora y el mantenimiento de los protocolos de Internet.

HTTP/2 y sus ventajas

Aunque el primer borrador de HTTP2 se presentó en el año 2012, no se empezó a implementar hasta el año 2015.

El primer navegador web que estuvo disponible fue Google Chrome y el primer servidor web fue LiteSpeed, el que utilizamos en todos nuestros hostings.

Aunque el proyecto inicial de HTTP2 nació usando como base el protocolo SPDY (de Google), cuando se comienza con el tema de la implementación se abandona el protocolo SPDY como base. El protocolo SPDY fue un protocolo complementario al protocolo HTTP presentado por Google y que, en principio, iba a ser la forma de mejorar el rendimiento al navegar por Internet (un 64%, según las pruebas de laboratorio). Por resumirlo de alguna forma, HTTP/2 mejora mucho la entrega de datos y eso hace que, en determinadas circunstancias, los datos se transfieran de una forma mucho más rápida al realizar comunicaciones asíncronas entre el cliente y el servidor. Vamos a listar las novedades que nos ofrece el protocolo HTTP2:

• Con HTTP2 se efectúa una única conexión para transferir cada recurso de la web, mientras que en HTTP 1.1 se abre una conexión para cada recurso de la web que se carga. Por resumirlo, en HTTP2 se abre una conexión, se envía toda la información del recurso y se cierra la conexión, mientras que en HTTP 1 se tenían que abrir múltiples conexiones para transferir un único archivo.
• HTTP2 elimina la información redundante o duplicada enviada durante una misma conexión. Con esto se reduce mucho la latencia en las conexiones y en las transferencias de información.
• Con HTTP2 se añade "multiplexación". La multiplexación nos permite enviar y recibir varias peticiones al mismo tiempo de forma asíncrona.
• Con el protocolo HTTP2 también se añade el servicio "server push". Esto consiste en que el servidor web (hosting) es capaz de enviar información al navegador del usuario incluso antes de que el navegador lo solicite. De esta forma, una petición realizada al servidor puede obtener varias respuestas.
• En cada petición HTTP se incluye información en las cabeceras que ayudan al receptor a entender el mensaje. En HTTP 2, esa información está comprimida con el algoritmo de compresión HPACK para que ocupe menos espacio y mejore el tiempo de transmisión.
• Un mensaje HTTP se suele dividir en varias partes que van por separado al transferirse desde el servidor al cliente (navegador web). Si estas partes llegan desordenadas al navegador del usuario, puede retrasarse la carga del recurso al faltar piezas necesarias para "montar el mensaje completo". Para esto, el protocolo HTTP 2 añade control de flujo, permitiendo asignar prioridades a las distintas partes de un mensaje HTTP.

Como puedes ver, todas estas características que acabamos de comentar están relacionadas con la velocidad de carga y la agilidad en la transferencia de datos en la relación cliente-servidor. Realmente, para poder notar algo se tienen que dar ciertas circunstancias específicas, pero mejora en cuanto a eficiencia hay siempre, aunque el usuario no llegue a percibirlo. Ahora vamos con algunas características adicionales que tiene el protocolo HTTP 2:

• A diferencia de HTTP 1, HTTP 2 es binario y eso hace que el nuevo protocolo sea menos propenso a tener errores.
• Con HTTP2 TLS es opcional, aunque la mayoría de los desarrolladores de navegadores han anunciado que se requerirá TLS versión 1.2 o superior.

Como puedes ver, el listado de mejoras de HTTP 2 es bastante larga, aunque la mayoría de los cambios se centran en mejorar la eficiencia del protocolo HTTP. Han pasado ya algunos años desde que se empezó a implementar HTTP/2 y podemos decir que hoy, a partir del año 2021, utilizar HTTP2 ya no es opcional, sino obligatorio. Al navegar por Internet en dispositivos de escritorio, posiblemente no podamos notar las mejoras de eficiencia, pero en el caso de dispositivos móviles con conexiones con bastante latencia ya se pueden notar las ventajas de HTTP2.

HTTP 2 y HTTPS

Uno de los cambios ocurridos entre 2015 y 2021 es que se ha popularizado el uso del protocolo HTTPS en lugar del HTTP, debido a que ahora los certificados SSL gratuitos son bastante comunes. Uno de los "problemas" que tiene HTTPS es que necesita que cada una de las conexiones sea cifrada y esto consume recursos y gasta tiempo, al menos tal y como estaban planteadas las comunicaciones en HTTP 1.1. Una de las mejoras de eficiencia de HTTP 2 es que abre una única conexión para transferir todos los paquetes con toda la información que da forma a un recurso. Esto es muy beneficioso cuando usamos HTTPS, ya que de esta forma solo consumiremos recursos y tiempo para encriptar 1 conexión, no varias. Esto hace que, al usar HTTP 2 (y HTTP 3), se consiga más velocidad al descargar la información, al tener que encriptar muchas menos conexiones durante la carga de una web.

HTTP/3 y sus ventajas

En el año 2019 comenzó la implementación de HTTP/3. El primer navegador web en ser compatible fue Google Chrome y el primer servidor web fue LiteSpeed. El protocolo HTTP 3 no añade tantas mejoras a HTTP 2 como HTTP 2 a HTTP 1.1. Inicialmente, HTTP 3 se llamaba HTTP over QUIC, ya que realmente es HTTP 2 funcionando sobre el protocolo QUIC. Y ahora vamos a hablar de QUIC. QUIC son las siglas de Quick UDP Internet Connections, se trata de un protocolo de red desarrollado inicialmente por Google que funciona a más bajo nivel que HTTP y que sirve para transferir datos a través de UDP, ayudando a controlar la congestión. HTTP 1 y HTTP 2 funcionan sobre TCP, pero QUIC aporta a HTTP 3 la capacidad de trabajar sobre UDP. A efectos prácticos, QUIC ayuda a mejorar las comunicaciones en circunstancias en las que hay bastante latencia y poco ancho de banda, es decir, en conexiones móviles cuando el "cliente" está ubicado geográficamente en una zona sin cobertura o cuando algún factor externo provoca interferencias.

¿Cómo saber qué versión de HTTP utilizamos?

Evidentemente, creo que no hay mucho que decir. Cuanto más reciente sea la versión del protocolo HTTP que utilicemos, mejor. El problema es que no depende directamente de nosotros, ya que la versión de HTTP usada en las comunicaciones y en la transferencia de datos cliente-servidor se "negocia" en el momento de la conexión. Esto quiere decir que, si usamos un navegador web compatible con HTTP 3 y el hosting de la web a la que accedemos solo es compatible con HTTP 1.1, la conexión se realiza en HTTP 1.1. Para garantizar que nuestro navegador web utiliza HTTP 3 simplemente debemos actualizarlo a la última versión disponible, teniendo en cuenta que sea uno de los más comunes. En caniuse.com siempre muestran gráficas para que puedas ver visualmente cuál es la primera versión compatible con una tecnología. En este caso, para HTTP 2: https://caniuse.com/?search=http2 Y para HTTP 3 tenemos esta gráfica: https://caniuse.com/?search=http3 La gráfica de HTTP 2 está completa pero en el caso de HTTP 3, en el momento de publicar este artículo, hay unos cuantos navegadores web que aún no son compatibles o solo son compatibles parcialmente con la versión 3 del protocolo HTTP. En el caso del servidor web, debemos preguntar a nuestro proveedor de hosting o probar con un test online como este: https://http3check.net/ También podemos utilizar las herramientas de desarrollador de Google Chrome (mi herramienta WPO favorita) si tenemos un poco de pericia: Si no ves la columna que he marcado en la pantalla anterior, haz clic derecho sobre la cabecera de la columna y podrás seleccionar para que te salga el "Protocolo".

En el caso de Raiola Networks, todos nuestros productos de alojamiento web utilizan HTTP 3.

No hay nada más que puedas hacer para cambiar de versión del protocolo HTTP. Tu única opción es intentar asegurarte de que ambos "actores" en la conexión cliente-servidor tengan la última versión de HTTP.