1. Introducción
2. Una breve historia de HTTP
   • SPDY
3. HTTP/2
4. ¿Tendremos que cambiar nuestros sitios web?
5. ¿Qué es lo que tenemos que cambiar para recibir HTTP/2?
   • Cambio a TLS
   • Convirtiendo multiples imágenes en una imagen “segmentada” (sprite)
   • Imágenes en línea utilizando data URIs (identificador de recursos uniforme)
   • La concatenación de CSS y Javascript
   • División de los recursos entre hosts: Sharding
6. Cómo prepararse para HTTP/2
   • Crear assets individuales además de sprites y datos uri
   • Organizar los assets por secciones
   • Gestionar sharding de dominio
   • Más por venir
7. ¿Cuándo cambiar?
8. El plan de acción para HTTP/2

Introducción

El Protocolo de transferencia de hipertexto (HTTP) es el protocolo que regula la conexión entre el servidor y los navegadores de los visitantes. Por primera vez desde 1999, se ha desarrollado una nueva versión de este protocolo y promete sitios web mucho más rápido para todo el mundo.

En este artículo, vamos a ver los conceptos básicos de HTTP/2 que se aplican a los diseñadores y desarrolladores web. Vamos a explicar algunas de las características clave del nuevo protocolo, comprobar la compatibilidad del navegador y del servidor, y detallar lo necesario para la adaptación a HTTP/2. Obtendremos una visión general de lo que debemos considerar para el cambio en nuestro ritmo de trabajo a corto y largo plazo. También incluiremos otros recursos si se quiere indagar más en las cuestiones que plantearemos. Nuestro objetivo es darle suficiente fondo para poder tomar buenas decisiones al planear el paso a HTTP/2.

Una breve historia de HTTP

HTTP es un protocolo antiguo, definido inicialmente en 1991, con la última revisión importante (HTTP/1.1) publicada en 1999. Los sitios web de 1999 son muy diferentes a los sitios web que se desarrollan en la actualidad. En HTTP/2 explained (describe el protocolo HTTP/2 desde un punto de vista técnico y a nivel de protocolo, “Background, the protocol, the implementations and the future” – Daniel Sternberg), Daniel Sternberg señala que la cantidad de datos que ahora se requieren para cargar la página principal de un sitio web promedio es de 1,9 MB, con más de 100 recursos individuales necesarios para visualizar una página (un «recurso» puede ser cualquier cosa, desde una imagen o un tipo de letra a un archivo CSS o JavaScript).

HTTP/1.1 no funciona bien cuando se recuperan una gran cantidad de esos recursos para visualizar una página web moderna. Como veremos más adelante en este artículo, muchas de las prácticas recomendadas de rendimiento que se conocen por ser desarrollador web, provienen de hacer frente a las limitaciones de HTTP/1.1.

2.1 SPDY

En 2009, dos ingenieros de Google publicaron acerca de un proyecto de investigación en el que habían estado trabajando, el llamado SPDY. Este proyecto se centraba en «arreglar» algunos de los problemas de HTTP/1.1.

SPDY se dispuso a:

1. Permitir solicitudes simultáneas a través de una única conexión TCP, conocida como multiplexación.
2. Permitir a los navegadores priorizar los recursos de la página para que el servidor los sirva primero.
3. Comprimir y reducir las cabeceras HTTP.
4. Implementar servidor push, por el que un servidor puede enviar recursos prioritarios al navegador antes de que se pidan.

Además, SPDY requiere una conexión cifrada (HTTPS) entre el navegador y el servidor.

SPDY no reemplaza a HTTP, más bien, se trata de un túnel para el protocolo que modifica la forma en que se envían las solicitudes y respuestas HTTP existentes. Se requiere apoyo tanto del servidor como del navegador que se conecta a ese servidor. Con el soporte disponible de Nginx y los paquetes disponibles en Google para habilitar el soporte con Apache, había una cantidad razonable de adaptación de SPDY. El soporte de los navegadores es bastante bueno ya que las versiones modernas de los navegadores más importantes lo soportan.



HTTP/2

Hemos visto a SPDY disfrutar de cierto éxito, ganando soporte con los servidores y navegadores. Sin embargo, a pesar de que Internet Explorer 11 soporta SPDY, Microsoft Edge no lo hace.

El soporte para SPDY ha decaído en Edge debido a la implementación de Microsoft para el soporte de HTTP/2, la última versión del protocolo HTTP. Mientras que otros navegadores actuales siguen manteniendo soporte para SPDY, Chrome eliminará el soporte en el año 2016, y los otros navegadores es probable que les sigan. En el momento de escribir esto, Edge, Firefox, Chrome y Opera soportan tanto SPDY como HTTP/2. Safari, incluido en iOS, se unirá a ese grupo a finales de este año con el lanzamiento de Safari 9.



HTTP/2 se basa en el éxito de SPDY, que fue utilizado como punto de partida para el nuevo protocolo. Como tal, la mayoría de los objetivos de SPDY están reunidos en HTTP/2. El requisito de una conexión HTTPS ha decaído. Dicho esto, todos los fabricantes de navegadores han decidido implementar solamente HTTP/2 para TLS (HTTPS). Así, mientras puedes estar utilizando HTTP/2 mediante texto plano en las comunicaciones entre servidores, en nuestro caso, para servir HTTP/2 a nuestros visitantes, necesitamos tener nuestro servidor sobre HTTPS antes de siquiera pensar en comenzar a migrar a HTTP/2.

La especificación HTTP/2 se finalizó en febrero de 2015; un año después, el soporte de HTTP/2 en los navegadores modernos es excelente. Al igual que con SPDY, HTTP/2 requiere soporte tanto a nivel de navegador como de servidor. W3Techs también tiene una entrada en el año 2015 a partir de julio en la que detalla las tasas de adopción.

¿Tendremos que cambiar nuestros sitios web?

HTTP/2 es compatible con HTTP/1.1, por lo que es posible ignorar por completo a HTTP/2 y todo seguirá funcionando con normalidad. El cambio de protocolo es completamente transparente para los usuarios. Muchos lectores de este artículo han estado utilizando un protocolo distinto de HTTP/1.1 durante años. Si tenemos una cuenta de Gmail y utilizamos Chrome para acceder a ella, habrán estado utilizando SPDY y luego HTTP/2 sin darse cuenta siquiera.

Sin embargo, muchas de las cosas que se creen como “prácticas recomendadas” pueden ser perjudiciales para el rendimiento de HTTP/2. Con el tiempo, cuantos más servidores se actualicen a HTTP/2 y más personas tengan navegadores que soportan HTTP/2, nuestro sitio web, a pesar de estar bien optimizado de acuerdo a las prácticas recomendadas, comenzará a parecer más lento que los sitios web optimizados para el nuevo protocolo.

¿Qué es lo que tenemos que cambiar para recibir HTTP/2?

Como hemos visto, la transición será un proceso lento para muchos sitios web. Para mover a HTTP/2, tendremos que actualizar el software del servidor para soportar el nuevo protocolo (que puede ser fácil o casi imposible dependiendo de cómo estén alojados).

Antes de realizar cambios en nuestro sitio web específicos para HTTP/2, también tendremos que considerar si los visitantes van a tener navegadores que lo soporten. Los propietarios de sitios web que atraen a una gran cantidad de personas que utilizan navegadores actualizados, serán capaces de hacer el cambio antes que los propietarios de los sitios web cuyos logs muestren que la mayoría de los usuarios usan navegadores antiguos.

5.1 Cambio a TLS

Si se desarrolla un nuevo sitio o se actualiza uno viejo, el primer paso debe ser asegurarse de que el sitio web esté en HTTPS tan pronto como sea posible. Esto es importante no sólo para HTTP/2, si no también como por ejemplo Google, que utiliza conexiones seguras como un indicio de clasificación, y los navegadores web están empezando a marcar sitios web sin HTTPS como «no seguros». En el futuro, algunas de las características más importantes de HTML5, tales como geolocalización, serán imposibles sin una conexión segura.

Si un sitio web que se encuentra actualmente en HTTP, se debe priorizar primero el cambio a HTTPS y luego decidir la estrategia de migración a HTTP/2.

5.2 Convirtiendo múltiples imágenes en una imagen “segmentada” (sprite)

En HTTP/1.1, descargar una imagen grande es mucho más eficiente para el navegador que hacer una gran cantidad de peticiones de pequeñas imágenes. Esto se debe a que las múltiples peticiones hacen cola una detrás de otra. Para evitar esto, se recomienda convertir nuestros iconos pequeños en un sprite, de forma que una única imagen contiene todas las necesarias para nuestra página web, de forma que podamos escoger que parte de la imagen queremos mostrar en un espacio concreto de nuestra web (un botón por ejemplo).

La imagen resultante se convierte en una única petición HTTP, evitando el problema de las múltiples peticiones en cola. No obstante, incluso si el visitante está en una página que muestra sólo uno de esos iconos, todavía se tiene que descargar un archivo mucho más grande de lo necesario con el fin de ver un icono o imagen.

Con la capacidad de multiplexación de HTTP/2, que pone en cola los recursos, ya no es un problema. Sirviendo las imágenes pequeñas de forma individual es más eficiente en muchos casos; sólo se tendrá que servir lo que se requiere para la página en la que el visitante se encuentre. La creación de un sprite sigue estando justificada en algunos casos; las peticiones HTTP son sólo un aspecto de mejora de rendimiento. La combinación de las imágenes juntas en un sprite podría lograr una mejor compresión y, por lo tanto, un tamaño de descarga menor en general, especialmente si todas esas imágenes se utilizan en la página que se está cargando. Sin embargo, ahora ya no será el caso de que un sprite sea siempre la mejor opción.

5.3 Imágenes en línea utilizando data URIs (identificadores de recursos uniforme)

Otra solución para el problema de las múltiples peticiones HTTP en HTTP/1.1 son las imágenes en línea en CSS utilizando URIs de datos. La incorporación de imágenes de esta manera hace que un CSS sea mucho más grande. Si se combina esto con otra técnica de optimización para concatenar los recursos, entonces, es muy probable que los visitantes descarguen todo este código CSS, incluso si nunca visitan las páginas en las que se están utilizando estas imágenes.

Con las solicitudes HTTP con menor coste computacional en HTTP/2, esta práctica recomendada obstaculizará más que contribuirá a su rendimiento.

5.4 La concatenación de CSS y Javascript

Como última instancia en nuestro proceso de construcción, muchos de nosotros concatenaremos todos los pequeños archivos CSS y JavaScript que se utiliza en nuestro sitio web. Muchas veces queremos mantener estos separados mientras desarrollamos para que sea más fácil de administrar estos recursos (pero sabemos que la entrega de un archivo al navegador es más eficiente que la entrega de cinco). Una vez más, estamos tratando de limitar las peticiones HTTP.

Si estamos haciendo esto, un visitante que entre en la página principal descargará todos los CSS y JavaScript necesarios para nuestra página web, incluso si nunca utilizan la mayor parte de ellos. Como desarrolladores, podemos solucionar este problema mediante la selección cuidadosa incluyendo archivos específicos para cada área de la página web en su proceso de construcción, pero esto requiere una alta cantidad de trabajo.

Un problema adicional con la concatenación es que tendrá que ser purgada de la caché toda a la vez. No podemos ofrecer archivos que nunca caduquen mientras ofrecemos otros con caducidades cortas. Todo tiene que caducar si una sola línea de CSS, que se utiliza en una sola página, cambia.

Las peticiones HTTP tienen un coste computacional menor en el mundo de HTTP/2. La organización de los recursos durante el desarrollo de acuerdo a las páginas en las que se van a utilizar será mucho mejor. Podemos ofrecer solo el código necesario para el visitante sin hacer que se descargue todo, lo use o no. La descarga de un montón de hojas de estilo pequeñas no importará. También podríamos organizar en base a la frecuencia con que modificamos las cosas; recursos que cambiamos poco podrían ser mantenidos por más tiempo.

5.5 División de los recursos entre hosts: Sharding

Con HTTP/1.1, se limitan al número de conexiones abiertas. Si la carga de un gran número de recursos es inevitable, un método de evitar esta restricción de conexiones es recuperarlos desde múltiples dominios. Esto se conoce como sharding de dominio. Podemos lograr mejores tiempos de carga, sin embargo, puede causar problemas, por no hablar de los gastos generales de desarrollo para la preparación del sitio web.

HTTP/2 elimina la necesidad de sharding de dominio porque se pueden solicitar tantos recursos como sean necesarios. De hecho, con esta técnica de sharding es muy probable que perjudiquemos el rendimiento, ya que creamos conexiones TCP adicionales y dificulta a HTTP/2 la priorización de los recursos.

Cómo prepararse para HTTP/2

Si vamos a iniciar un proyecto en el que esperamos tener cierta durabilidad, pero no podemos ponerlo en marcha sobre HTTP/2 inmediatamente debido a la compatibilidad de los servidores, valdría la pena considerar cómo podemos prepararnos para HTTP/2. Podemos añadir un par de cosas a nuestro proceso de desarrollo para hacer más sencillo el cambio después.

6.1 Crear recursos individuales además de sprites y datos URI

Si vamos a crear sprites, añadiremos al proceso de creación y optimización recursos individuales, o también podemos añadir sprites específicos de cada página más pequeños, esto hará que sea más fácil cambiar de sprites grandes a pequeños (o no) cuando alcancemos el punto de inflexión para nuestro sitio web.

La misma verdad para los datos URI. Si estamos usando estos en nuestro CSS, deberemos de tener las imágenes listas para cuando sustituyamos esta técnica innecesaria en HTTP/2.

6.2 Organizar los recursos por secciones

Con la concatenación de CSS y JavaScript, hay tentación de optimizar para facilitar el desarrollo ya que los archivos se guardan todos juntos de todos modos. Cuando se cambia a HTTP/2, vamos a obtener más rendimiento si gestionamos cuidadosamente los recursos para que sólo lo necesario se cargue en una página. Por lo tanto, comenzar a organizar nuestro desarrollo de este modo vale la pena. Por ahora, es posible comenzar concatenando CSS y JavaScript, y cuando alcancemos el punto de inflexión, podemos detener esa parte del proceso de construcción y servir los recursos de forma individual.

6.3 Gestionar sharding de dominio

Lo mejor actualmente para HTTP/1.1 es limitar el sharding a dos hosts. Hay una manera de conseguir que HTTP/2 conviva con más de una conexion, si el certificado TLS es válido para ambos hosts y estos se resuelven en la misma IP. Dado que los navegadores requieren HTTP/2 para ejecutarse a través de HTTPS, es necesario obtener el certificado TLS para funcionar sobre HTTP/2. Podemos obtener más información en la diapositiva 26 de la presentación de Ilya Grigorik en la Velocity Conference.



6.4 Más por venir

En última instancia, pondremos toda una serie de prácticas recomendadas para HTTP/2. Para un mejor rendimiento, este protocolo nos ofrece un gran control, lo que significa que tendremos que tomar nosotros las decisiones para cada proyecto. Esta tecnología nos permite decidir qué recursos son prioritarios y obliga al servidor a entregarlos antes que las cosas “menos importantes”.

¿Cuándo cambiar?

Para los diseñadores y desarrolladores que no tienen el control total sobre la infraestructura donde despliegan sus webs, la decisión no la pueden tomar hasta que los servidores que utilizan sean actualizados. Actualmente ya existen compañías de hosting que ofrecen soporte para HTTP/2 (incluso para hosting compartido), por lo que desplegar sobre un servidor compatible es algo que podemos recomendar a los clientes si creemos que les beneficiara.

Una vez nuestra página web este alojada en un servidor compatible con HTTP/2, la decisión de seguir optimizándola para HTTP/1.1 o para HTTP/2 recaerá sobre el protocolo que soporten la mayoría de nuestros usuarios. Recordemos que HTTP/2 es retrocompatible, no necesitamos hacer nada en especial. La decisión que debemos tomar es cuando optimizarla para ello.

Para decidirnos, debemos hacerlo de acuerdo a nuestros análisis de datos. Si la mayoría de los visitantes utilizan navegadores que soportan HTTP/2 o no, entonces comprendemos que existen un punto de inflexión sobre la decisión de optimizar nuestra web para esos usuarios. Muchos de nosotros ya habremos llegado a ese punto. Podemos utilizar herramientas como “caniuse.com” o reunir nuestra propia información para conocer a nuestros usuarios finales. Por ejemplo, muchos de los beneficios de HTTP/2 tendrán más impacto sobre los dispositivos móviles. Si tenemos un alto tráfico proveniente de dispositivos móviles puede ser un indicativo para pasarnos a HTTP/2. Sin embargo, si tenemos un alto tráfico desde dispositivos móviles que utilizan Opera Mini como navegador, puede ser razón suficiente para esperarnos a dar el paso hacia HTTP/2 ya que aún no tiene soporte para móviles.

Si a día de hoy estamos construyendo una nueva web, sugerimos centrarse en optimizar HTTP/2 durante las fases de desarrollo. Si durante el lanzamiento sentimos la necesidad de hacer retoques para HTTP/1.1 debido a la compatibilidad de los navegadores, mucho puede realizarse en el proceso de construcción, permitiéndonos cambiar a HTTP/2 tan pronto como veamos conveniente.

El plan de acción para HTTP/2

1. Lanzamiento con una conexión segura o cambiar a TLS ahora. Esta debe ser nuestra prioridad.
2. Preparar HTTP/2 en su proceso de construcción. Cualquier sitio web que construyamos ahora probablemente se beneficiaría de ser optimizado para HTTP/2. Utilicemos las sugerencias anteriores para crear un proceso de construcción que puede ser optimizado para ambos protocolos.
3. Ver nuestras estadísticas. Al comparar el uso de los distintos navegadores en nuestra página web con la tabla de soporte en “caniuse.com”, podemos ver qué porcentaje de visitantes se beneficiarían de una optimización para HTTP/2.
4. Comprobar el soporte de nuestro hosting. Cuando llegue el momento en que nos beneficiemos del cambio, tendremos que asegurarnos de que nuestro servidor soporte HTTP/2. Hablar con nuestro proveedor de hosting o el administrador de los servidores para informarnos sobre sus planes de migración.
5. Desplegar optimización para HTTP/2. Una vez que el servidor soporte HTTP/2, el resto depende de nosotros. Dejar de usar las viejas prácticas recomendadas y cambiar a las nuevas. Esto significa que los usuarios con navegadores que no soportan HTTP/2 tendrán una experiencia más desagradable, por lo que el encargado detrás del cambio debe tener muy claro cuando que la mayoría se beneficiaría de este cambio.

Cuando pasemos a HTTP/2, puede ser interesante medir el incremento de rendimiento y ver qué técnicas son las que nos aportan una mayor diferencia en nuestra página web.

Traducción de Getting Ready For HTTP/2