Introducción a HTTP/2 y velocidad de página

Publicado: 2020-01-03

Introducción

En 1991, se introdujo la primera versión documentada del protocolo HTTP de solicitud-respuesta (HTTP 0.9). Desde entonces, la web se ha expandido drásticamente y, 24 años después, se lanzó la versión más reciente del Protocolo de transferencia de hipertexto (HTTP/2) en 2015, que presenta una multitud de posibles beneficios para el rendimiento del sitio cuando se implementa correctamente.

Este artículo está dirigido a los SEO que deseen implementar HTTP/2 como parte de sus iniciativas de optimización de la velocidad de la página.

HTTP/2 es un tema extremadamente rico que podría discutirse con gran detalle. Hay una gran cantidad de información en línea sobre HTTP/2 y sus beneficios más amplios para los usuarios finales y los desarrolladores, pero antes de sumergirse en la gran cantidad de información sobre HTTP/2, asegúrese de obtener la información que necesita. Esto comienza con hacer las preguntas correctas:

  1. ¿Cómo afectará esto directamente la optimización del motor de búsqueda y/o la velocidad de la página?
  2. ¿Se puede hacer una recomendación a partir de la información?
  3. ¿Se puede llevar a cabo la recomendación de manera realista?

Estas preguntas lo ayudan a preguntarse "¿lo que estoy haciendo es efectivo y valioso?" y, en última instancia, lo pondrá en una mejor posición para evaluar cómo HTTP/2 puede ayudar a mejorar un sitio web.

Debido a la naturaleza amplia del tema, existe una gran cantidad de conocimientos sobre HTTP/2 que no son necesarios cuando se trata de comprender la importancia para el SEO. El principal beneficio de HTTP/2 para SEO es la velocidad de la página.

Para ayudarlo a navegar a través de la gran cantidad de información en línea, aquí hay una introducción a HTTP/2, que describe la evolución desde HTTP 1.1 hasta Spdy compatible con HTTP de Google y finalmente a HTTP/2.

Comprender cómo ha evolucionado la web ayudará a resaltar las mejoras que se le han realizado como consecuencia de la adición del protocolo HTTP/2.

¿Cómo evalúa Google la velocidad de la página?

Para ver cómo Google evalúa la velocidad de la página, no busque más allá de los informes de experiencia del usuario de Chrome . Estos informes proporcionan métricas de la experiencia del usuario sobre cómo los usuarios experimentan destinos populares en la web. Esto se basa en métricas clave de participación del usuario (primera pintura, primera pintura con contenido, primera pintura significativa, tiempo de interacción) y se admite aún más a través de herramientas comunes como Page Speed ​​Insights, Public Google Big Query Project, Lighthouse y Web Page Test. El uso de estas métricas y herramientas puede ayudar a realizar posibles mejoras en Page Speed.

Introducción a HTTP/2

HTTP 1.1

Para 2015, HTTP 1.1 se había quedado obsoleto. Atrás quedaron los días en que las páginas/sitios web se creaban/se basaban en HTML básico, CSS y JavaScript, y numerosos recursos y marcos diferentes. La era anterior a 2015 se basaba en la idea de que estaba limitado a una solicitud por conexión TCP. Esto conducía a situaciones en las que los clientes web tenían varios recursos en cola para descargar, lo que provocaba la congestión de la red y tiempos lentos de carga de la página.

HTTP/2 fue diseñado para apuntar a tres áreas principales de mejora para aliviar los problemas discutidos anteriormente:

  • Sencillez
  • Alto rendimiento
  • Robustez

Beneficios de SEO para HTTP/2

La velocidad de la página es probablemente la razón principal por la que los SEO considerarían implementar HTTP/2 en sus propios sitios web o en los de sus clientes. Page Speed/Rendimiento es un conjunto de métricas que han sido un factor de clasificación desde 2010 para consultas de escritorio. Debido al aumento del uso de dispositivos móviles, en julio de 2018, Google anunció oficialmente que Page Speed ​​se convertiría en un factor de clasificación para dispositivos móviles.

HTTP/2 proporciona 3 funcionalidades principales que se pueden utilizar al optimizar sitios para Page Speed:

  1. multiplexación
  2. Empuje del servidor
  3. Priorización de transmisión

multiplexación

La multiplexación permite que un cliente web incluya varias solicitudes dentro de una única conexión TCP, lo que reduce la carga del servidor y reduce la congestión de la red.

Los clientes web modernos (Chrome, Firefox, Safari y Opera) que utilizan los protocolos HTTP 1/1.1 más antiguos tienen un límite predeterminado en la cantidad de conexiones TCP simultáneas por nombre de host. Por lo tanto, un cliente web que utiliza HTTP 1/1.1 puede tener problemas fácilmente con la congestión de TCP. Con los clientes web modernos, este problema se resuelve mediante la multiplexación, que puede brindar algunas de las mejoras más significativas en la velocidad de la página.

A continuación se demuestra el beneficio de la multiplexación mediante una comparación de HTTP/1.1 y HTTP/2, que muestra el comportamiento típico cuando la multiplexación HTTP/2 está y no está habilitada.

( Prueba de página web, HTTP/1.1, sin demostración de multiplexación )

( WebpageTest, HTTP/2, multiplexación demostrada )

En las imágenes anteriores, se utiliza una cascada basada en el rendimiento para demostrar la carga de recursos entre un usuario (que solicita los recursos) y el servidor (que responde cuáles son los recursos) de una página web. Por lo general, los recursos de la página incluyen HTML, JavaScript, CSS e imágenes. La cascada basada en el rendimiento demuestra el punto exacto en el que se llama, descarga y procesa un recurso específico dentro del cliente, lo cual es fundamental para descubrir, evaluar y analizar los problemas de velocidad de la página en un sitio. Como lo demuestra la imagen de arriba "HTTP/2", todos los recursos comienzan a descargarse simultáneamente sin que ningún recurso comience a cargarse en un punto diferente. Como HTTP/2 utiliza multiplexación y ya no se basa en enviar solo 1 solicitud a través de una sola conexión TCP, se pueden descargar múltiples recursos al mismo tiempo como se ve arriba. Por el contrario, como lo demuestra la imagen "HTTP/1.1", los recursos no se descargan al mismo tiempo, ya que no pueden utilizar la funcionalidad de multiplexación. El navegador moderno promedio bajo HTTP/1.1 puede tener 6 conexiones simultáneamente, pero el beneficio de implementar HTTP/2 es que no se necesita un protocolo de enlace TCP para cada solicitud, mientras que no importa cuántas conexiones se puedan ejecutar simultáneamente con HTTP/1.1. El proceso de conexión debe completarse cada vez. Por lo tanto, comienzan a descargarse en diferentes puntos, lo que provoca una carga de página más prolongada para el usuario.

( Diagrama Upwork HTTP/1.1 frente a HTTP/2 )

Los rastreadores de búsqueda como Google y Bing no se benefician directamente de la implementación de HTTP/2. Como se describió anteriormente, el principal beneficio de estas optimizaciones podría ser para Page Speed. Por lo tanto, aunque es posible que la implementación de HTTP/2 no afecte directamente al rastreador de búsqueda, puede afectar la velocidad de la página, que es un factor de clasificación directo para las consultas de Google para escritorio desde 2010 y las consultas móviles desde julio de 2018. Como resultado, es fundamental que los sitios web no entreguen una experiencia lenta para los usuarios, ya que Google puede suprimir el rendimiento al afectar las clasificaciones o, más recientemente, señalar a los usuarios que su sitio puede ser lento.

Empuje del servidor

Server Push permite que el servidor específico o la red perimetral envíen recursos a los clientes web cuando el cliente no los ha solicitado. Para comprender cómo funciona la inserción del servidor, primero es importante comprender el patrón de solicitud-respuesta que sigue un sitio web. Un usuario solicita una página de un sitio web y el servidor responde con el contenido/recurso solicitado.

Hipotéticamente, piense en un sitio que tiene todos sus estilos definidos en una hoja de estilo externa llamada estilos.css. Cuando el usuario solicita el esqueleto HTML para la página (digamos en este caso, index.html), el servidor push puede "enviar" el CSS al usuario justo después de comenzar a enviar la respuesta a index.html.

( Revista aplastante, Empuje del servidor )

Antes de comprender cómo Server Push puede ayudar a mejorar la velocidad de la página, es importante comprender cómo funciona un navegador con diferentes recursos, como imágenes, CSS y JavaScript, para que aparezcan en su navegador. Verá, el navegador envía instrucciones sobre cómo descargar imágenes, CSS y recursos de JavaScript. Cuando visita un sitio web por primera vez, generalmente realiza una solicitud GET, que es el archivo .html. Una vez que se recibe este archivo .html, el navegador lo escanea para comprenderlo y luego puede realizar solicitudes GET adicionales según lo que contenga el archivo HTML.

¿Cómo ayuda Server Push a mejorar la velocidad de la página?

Mediante el uso de Server Push, se reduce la cantidad de solicitudes GET necesarias del navegador (viajes de ida y vuelta) y se evitan los retrasos en el procesamiento que provocan un aumento en los tiempos de carga de la página. Esto puede ayudar dramáticamente a mejorar el tiempo de renderizado para el cliente web, lo que ayuda a que la página web aparezca más rápido para los usuarios, brindándoles así una experiencia mucho mejor.

Si bien Server Push no afecta directamente la forma en que Googlebot rastrea su sitio, o de hecho otros rastreadores, el beneficio de SEO se obtiene a través de mejoras en los factores centrados en el usuario, como First Paint y First Meaningful Content.

Con la prueba de página web, Lighthouse, Page Speed ​​Insights y el informe de experiencia de usuario de Chrome, puede determinar el rendimiento de un sitio/página en comparación con los competidores dentro de las mismas industrias. A continuación se muestran dos imágenes que demuestran la implementación sin (Imagen 1) y con Server Push (Imagen 2).

(Prueba de página web, sin inserción de servidor)

(Prueba de página web, HTTP/1.1, con inserción de servidor)

Con la inserción del servidor, el servidor se puede configurar para que siempre envíe cualquier componente de página adicional (como archivos CSS, JavaScript e imágenes) si se le solicita que envíe el archivo .html que los contiene.

En las cascadas de arriba podemos ver que push.php usa cuatro archivos CSS.

Sin inserción del servidor, el navegador necesita recibir el archivo push.php, analizar el HTML y luego realizar solicitudes específicas para cada archivo CSS adicional. Solo una vez que haya recibido todos los archivos CSS puede comenzar a usarlos en el proceso de renderizado.

Cuando la inserción del servidor está habilitada, la solicitud de push.php activa automáticamente el servidor para enviar los cuatro archivos CSS. El navegador los recibe y puede comenzar a usarlos en el proceso de renderizado mucho antes. Esto significa que el navegador puede comenzar a mostrar el contenido de la página mucho antes, lo que da como resultado mejores métricas de velocidad de la página.

Priorización HTTP/2

La priorización HTTP/2 entrega el control del orden en que se cargan los recursos a los propietarios del sitio. Si se realiza correctamente, la priorización beneficia la experiencia del usuario y la velocidad de la página/sitio al entregar los recursos de la página en un orden optimizado, creando así una experiencia de usuario "rápida".

Si observamos el predecesor de HTTP/2, HTTP/1.1, el cliente web controlaba el orden en que se cargaban los recursos. Como se discutió anteriormente, esto se debió al hecho de que cada conexión TCP solo podía admitir un recurso a la vez. Depende del navegador programar solicitudes decidiendo qué recursos elegir y cuántas conexiones abrir en paralelo.

Antes de entrar en cómo se hace, es importante comprender por qué querríamos utilizar la priorización de nuestros recursos.

Si tenemos una imagen en la parte superior de una página y una imagen en la parte inferior de la página, lógicamente nos gustaría asegurarnos de que la imagen en la parte superior se cargue antes que la imagen en la parte inferior. Este concepto ayuda a demostrar la importancia y el impacto que puede traer la priorización de HTTP/2. La priorización de HTTP/2 nos permite especificar qué recursos se deben entregar primero y cargar antes que otros (ya sean JavaScript, CSS o imágenes), lo que garantiza el tiempo de carga más rápido para la página.

Si bien el navegador ahora puede solicitar múltiples recursos simultáneamente a través de una sola conexión TCP usando multiplexación, ahora también puede especificar información de prioridad con cada solicitud para ayudar a determinar cuándo y cómo se debe entregar el recurso. Si tanto el servidor como el navegador admiten la priorización HTTP/2, el navegador debe definir las reglas de priorización utilizando el ancho de banda completo sin que los recursos compitan entre sí. Para comprender mejor cómo funciona el proceso de priorización, es importante discutir tres parámetros que son importantes para la priorización de HTTP/2:

Flujo: este es un flujo bidireccional de bytes dentro de una conexión establecida que puede transportar uno o más mensajes.

Corriente principal: esta es una corriente de la que dependen los recursos

Secuencia secundaria: esta es una secuencia dependiente de la secuencia principal. Comparten el mismo padre y, por lo tanto, se conocen como secuencias secundarias.

Peso: este es un número asignado entre 1 y 256 que identifica cuánto ancho de banda asignar a la transmisión si varias transmisiones comparten una conexión. El ancho de banda se asigna en relación con los pesos de todos los demás flujos activos.

Bit exclusivo: esta es una bandera que indica que la transmisión debe descargarse sin compartir el ancho de banda con ninguna otra transmisión.

Marco de encabezados: esta es la identificación del flujo al que pertenece el marco

Capa de trama binaria: así es como se encapsulan y transfieren los mensajes HTTP entre el cliente y el servidor

Un ejemplo a continuación demuestra un ejemplo de lo anterior:

( Priorización de transmisión HTTP/2 de Google Developers )

Para llevar a cabo la Priorización HTTP/2, deberá agregar información de priorización dentro del Marco de encabezados ubicado dentro de la nueva Capa de marco binario HTTP/2. El flujo principal y la dependencia/no dependencia de otros flujos secundarios determinarán la prioridad/ponderación y, por lo tanto, la entrega al cliente web del recurso.

Aunque la priorización de HTTP/2 ahora es compatible con numerosas plataformas, muchas CDN y proveedores de alojamiento no admiten la priorización de HTTP/2. Por lo tanto, es importante asegurarse de que está utilizando un proveedor de CDN/alojamiento que admita la priorización de HTTP/2 si desea utilizar esta técnica de optimización. A continuación se muestra una tabla que describe qué CDN/alojamiento/servidores pueden y no pueden admitir la priorización HTTP/2.

Priorización de HTTP/2 - Compatibilidad común de servidor/alojamiento/CDN

Esta comparación fue correcta el 01/02/2020 , pero vale la pena verificar si los posibles proveedores de servicios han mejorado su compatibilidad antes de tomar una decisión sobre cuál elegir.

También es importante observar de manera crítica los navegadores específicos porque, lamentablemente, no todos los navegadores admiten la priorización HTTP/2 y priorizan de manera diferente debido a que son diferentes clientes web. A continuación se muestra una tabla que describe qué clientes web pueden admitir la priorización HTTP/2.

Priorización HTTP/2 Compatibilidad con clientes web

La priorización de HTTP/2 puede mejorar significativamente la percepción de un usuario sobre la velocidad de la página/sitio y tendrá un impacto positivo en los datos acumulados en el Informe de experiencia del usuario de Chrome. Si bien esta optimización no tiene impacto en los rastreadores de búsqueda como Googlebot, herramientas como Lighthouse y Page Speed ​​Insights lo ayudarán a evaluar el impacto de la priorización de HTTP/2 en el rendimiento de la velocidad de la página desde la perspectiva del usuario.

Al configurar correctamente el peso de la transmisión tanto con el servidor como con el cliente utilizando un CDN/host compatible con HTTP/2, podrá mejorar drásticamente las métricas de velocidad de la página para su cliente.

¿Cuáles son los requisitos previos para HTTP/2?

Antes de poder aprovechar los beneficios de velocidad de HTTP/2, asegúrese de poder utilizarlo. Hay algunos requisitos previos que deben tenerse en cuenta:

  1. Es importante asegurarse de que HTTPS esté habilitado.
  2. Utilice un certificado TLS de una autoridad autenticada y active e instale el certificado.
  3. Asegúrese de que su software de servidor web, como Nginx, Apache e IIS, admita HTTP/2. Se puede encontrar una lista autenticada completa para soporte en http://ayi.ma/browsershttp2 que mostrará soporte de navegador para HTTP/2. Si está buscando compatibilidad con HTTP/2 para CDN/Hosting, consulte http://ayi.ma/serverhosting .

Errores comunes/cosas que deben cambiar con la introducción de HTTP/2

Debido a las limitaciones de los protocolos HTTP 1.0 y HTTP 1.1 anteriores, los desarrolladores y los SEO se han esforzado por encontrar formas de evitar la multitud de problemas que presentaban estas limitaciones para el rendimiento y la seguridad de la velocidad de la página.

Eventualmente, pudieron encontrar "trucos" para eludir algunas de estas limitaciones, pero muchos de estos métodos causaron aún más trabajo a los desarrolladores. ¿Cuáles son algunos de estos trucos que puedes preguntar? Estos son algunos de los hacks más comunes que verá en los sitios que se pueden resolver mediante la implementación correcta de HTTP/2.

Evite la fragmentación de dominios

Sorprendentemente, una multitud de sitios todavía usan este truco aunque tienen HTTP/2 implementado correctamente. Cuando HTTP/2 está habilitado, será importante evitar utilizar la fragmentación del dominio. Domain Sharding es la técnica de dividir recursos entre diferentes nombres de host, lo que permite que se sirvan más recursos simultáneamente.

Gracias al protocolo HTTP/2 actualizado, Domain Sharding ya no es necesario y, de hecho, causa más problemas de los que resuelve. Si HTTP/2 está correctamente configurado y habilitado para su sitio y también usa Domain Sharding, en realidad está contrarrestando algunos de los beneficios de HTTP/2, ya que el navegador no podrá beneficiarse de la multiplexación y las descargas en varios nombres de host.

Además, a través de Domain Sharding, en realidad está rompiendo la priorización de transmisión y sus recursos no podrán cargarse para aprovechar al máximo Page Speed.

Utilizar correctamente la inserción del servidor

Server Push tiene algunos inconvenientes que debe tener en cuenta. De hecho, Server Push puede usarse en exceso y debe ser selectivo al elegir cuándo usarlo. No necesariamente desea enviar demasiados recursos, ya que esto podría hacer que el cliente web descargue no solo HTML, sino todo lo que se "empuja". Esto significa que la página podría tardar más en cargarse y renderizarse (aumentando las métricas centradas en el usuario en las que Google se centra, como el tiempo de interacción).

Un segundo escollo común para la inserción del servidor es averiguar cómo no transferir los recursos que el cliente web ya tiene. Esto se puede controlar a través de numerosos métodos. Un método es optar por no enviar recursos a los usuarios que regresan y, por lo tanto, permitir que los usuarios que regresan utilicen sus activos almacenados en caché. Esta es, con mucho, la implementación más fácil. Esto se puede hacer simplemente revisando los encabezados de caché para los recursos, asegurándose de que los encabezados no se superpongan con la implementación de inserción del servidor.

Pruebas de la vida real bajo HTTP/2

El conocimiento teórico siempre es importante para sentar las bases para comprender HTTP/2 y sus beneficios. Una vez que se captan y comprenden los conceptos, es importante probar estas teorías para medir el impacto que HTTP/2 puede tener en Page Speed.

La parte 2 de esta serie sobre la velocidad de la página HTTP/2 en la vida real: el uso de pruebas y análisis de sitios web discutirá el verdadero beneficio de HTTP/2 con respecto a la velocidad de la página y el valor para el SEO, ¡así que no se lo pierda!

¿Qué pasa con HTTP/3?

Aunque HTTP/3 demuestra un claro potencial como protocolo sucesor de HTTP/2, no significa ni debería señalar el final de HTTP/2 para SEO en toda la web. Al igual que con cada nuevo desarrollo importante en la web mundial, pasará por una fase de implementación normal y probablemente llevará tiempo para que un sitio adopte el nuevo protocolo y antes de que se convierta en un estándar de facto dentro de la industria de SEO. La implementación de HTTP/2 aún representa una ganancia beneficiosa y simple que, cuando se implementa correctamente, puede ayudar a mejorar el rendimiento de su sitio.