Preparándose para HTTP2: una guía para diseñadores y desarrolladores web

El Protocolo de transferencia de hipertexto (HTTP) es el protocolo que rige la conexión entre su servidor y los navegadores de los visitantes de su sitio web. Por primera vez desde 1999, tenemos una nueva versión de este protocolo y promete sitios web mucho más rápidos para todos.

En este artículo, veremos los conceptos básicos de HTTP2 que se aplican a los diseñadores y desarrolladores web. Explicaré algunas de las características clave del nuevo protocolo , analizaré la compatibilidad del navegador y el servidor, y detallaré las cosas en las que podría tener que pensar a medida que veamos una mayor adopción de HTTP2.

Más lecturas sobre Smashing:

• Precarga: ¿Para qué sirve?
• Todo lo que necesitas saber sobre AMP
• Mejorando el rendimiento de la revista Smashing

Al leer este artículo, obtendrá una descripción general de lo que debe considerar cambiar en su flujo de trabajo a corto y largo plazo. También incluiré muchos recursos si desea profundizar más en los problemas planteados. Mi objetivo es brindarle suficientes antecedentes para que pueda tomar buenas decisiones mientras planifica su cambio a HTTP2.

Una breve historia de HTTP

HTTP es un protocolo antiguo, inicialmente definido en 1991, con la última revisión importante, HTTP/1.1, publicada en 1999. Los sitios web en 1999 eran muy diferentes a los sitios web que desarrollamos hoy. En http2 explicado , Daniel Sternberg señala que la cantidad de datos que ahora se requieren para cargar la página de inicio de un sitio web promedio es de 1,9 MB, con más de 100 recursos individuales necesarios para mostrar una página; un "recurso" es cualquier cosa, desde una imagen o una fuente. a un archivo JavaScript o CSS.

HTTP/1.1 no funciona bien cuando recupera la gran cantidad de recursos necesarios para mostrar un sitio web moderno. Como veremos más adelante en este artículo, muchas de las mejores prácticas de rendimiento que conocemos como desarrolladores web provienen de cómo lidiamos con las limitaciones de HTTP/1.1.

SPDY

En 2009, dos ingenieros de Google publicaron sobre un proyecto de investigación en el que habían estado trabajando llamado SPDY. Este proyecto abordó algunos de los problemas en HTTP/1.1. SPDY se propuso:

• permitir solicitudes simultáneas a través de una única conexión TCP, lo que se conoce como multiplexación ;
• permitir que los navegadores prioricen los activos para que el servidor pueda enviar primero los recursos vitales para mostrar una página;
• comprimir y reducir encabezados HTTP;
• implementar server push , mediante el cual un servidor puede enviar recursos vitales al navegador antes de que se le solicite.

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

SPDY no reemplaza a HTTP; más bien, es un túnel para el protocolo y modifica la forma en que se envían las solicitudes y respuestas HTTP existentes. Requiere soporte tanto del servidor como del navegador que se conecta a ese servidor. Con soporte disponible en NGINX y paquetes disponibles de Google para habilitar el soporte en Apache, hubo una cantidad razonable de adopción de SPDY. El soporte del navegador también es bastante bueno, con versiones modernas de todos los principales navegadores que lo admiten.

HTTP2

Hemos visto a SPDY disfrutar de cierto éxito, ganando adopción tanto en servidores como en navegadores. Sin embargo, es posible que también haya notado que, a pesar de que Internet Explorer 11 es compatible, el navegador Edge de Microsoft lo ha eliminado. ¿Que esta pasando aqui?

La compatibilidad con SPDY se eliminó en Edge debido a que Microsoft implementó la compatibilidad con HTTP2, la última versión del protocolo HTTP. Mientras que otros navegadores actuales aún mantienen la compatibilidad con SPDY, Chrome eliminará la compatibilidad en 2016 y es probable que otros navegadores lo sigan. Al momento de escribir, Edge, Firefox, Chrome y Opera son compatibles con SPDY y HTTP2. Safari, incluso en iOS, se unirá a ese grupo a finales de este año con el lanzamiento de Safari 9.

HTTP2 se basa en el éxito de SPDY, que se utilizó como punto de partida para el nuevo protocolo. Como tal, la mayoría de los objetivos de SPDY se cumplen en HTTP/2. Se eliminó el requisito de una conexión HTTPS. Dicho esto, todos los proveedores de navegadores han decidido implementar solo HTTP2 para conexiones TLS (https). Entonces, si bien podría usar HTTP/2 con texto sin cifrar en las comunicaciones de servidor a servidor, nuestro caso de uso de servir HTTP2 a los navegadores significa que necesita tener su sitio ejecutándose en https antes de siquiera pensar en cambiar a HTTP2.

La especificación HTTP2 se finalizó en febrero de 2015; un año después, la compatibilidad con los navegadores modernos es excelente. Al igual que con SPDY, HTTP2 requiere compatibilidad tanto a nivel de navegador como de servidor, y ya existen muchas implementaciones de servidores web. Puede realizar un seguimiento de estos en la wiki de HTTP/2. W3Techs también tiene una publicación de julio de 2015 que detalla las tasas de adopción. La adopción de este protocolo está ocurriendo rápidamente, considerando lo relativamente nuevo que es.

¿Tendremos que cambiar nuestros sitios web?

HTTP/2 es compatible con versiones anteriores de HTTP/1.1 , por lo que sería posible ignorarlo por completo y todo seguiría funcionando como antes. El cambio de protocolo es completamente transparente para los usuarios. Muchos lectores de este artículo habrán estado usando un protocolo diferente a HTTP/1.1 durante años. Si tiene una cuenta de Gmail y usa Chrome para acceder a ella, habrá estado usando SPDY y luego HTTP/2 sin saber nada al respecto.

Sin embargo, muchas de las cosas que considera mejores prácticas pueden ser perjudiciales para el rendimiento en HTTP/2. Con el tiempo, a medida que más servidores se actualicen para usar HTTP/2 y más personas tengan navegadores compatibles con HTTP/2, su sitio web, en un momento bien optimizado de acuerdo con las mejores prácticas, comenzará a parecer más lento que los sitios web optimizados para el nuevo protocolo.

¿Qué necesitamos cambiar para adoptar HTTP/2?

En el resto de este artículo, veremos algunas de las mejores prácticas comunes que se convertirán en antipatrones a medida que se adopte HTTP/2 . Como hemos visto, la transición será lenta para muchos sitios web. Para pasar a HTTP/2, el software de su servidor deberá actualizarse para admitir el protocolo, lo que puede ser fácil o casi imposible dependiendo de cómo esté alojado.

Antes de realizar cambios en su sitio web específicamente para HTTP/2, también deberá considerar si sus visitantes tienden a tener navegadores compatibles. Los propietarios de sitios web que atraen a muchas personas que usan navegadores muy actualizados podrán hacer ese cambio antes que los propietarios cuyos registros muestran que la mayoría de los usuarios utilizan navegadores más antiguos. Para reflejar esto, también les daré algunas sugerencias sobre cómo trabajar en este tiempo de transición.

Haga el cambio a TLS

Para muchos sitios web, lo más difícil de cambiar a HTTP/2 puede no ser HTTP/2 en absoluto, sino el requisito de ejecutar el sitio a través de una conexión segura. Si está desarrollando un nuevo sitio o actualizando uno antiguo, su primer paso debe ser asegurarse de iniciar o pasar a https lo antes posible. Esto es importante no solo para HTTP/2, Google usa conexiones seguras como una señal de clasificación y los navegadores están comenzando a marcar los sitios web que no son https como "no seguros". En el futuro, descubrirá que algunas potentes funciones de HTML5, como la geolocalización, no estarán disponibles sin una conexión segura.

Si tiene un sitio que actualmente es solo http, entonces mi sugerencia sería priorizar un movimiento a https primero y luego decidir su estrategia HTTP/2.

Convertir múltiples archivos de imagen en sprites

En HTTP 1.1, recuperar una imagen grande es mucho más eficiente para el navegador que hacer muchas solicitudes de imágenes pequeñas. Esto se debe a que hay varias solicitudes en cola una detrás de la otra. Para evitar esto, se nos ha recomendado convertir nuestros pequeños íconos en un archivo sprite.

El sprite resultante se devuelve con una solicitud HTTP, lo que evita el problema de que se pongan en cola varias solicitudes. Sin embargo, incluso si el visitante está en una página que muestra solo uno de esos íconos, aún tendrá que descargar un archivo mucho más grande de lo que necesita para ver esa imagen.

Con la capacidad de multiplexación de HTTP/2 , esta cola de recursos ya no es un problema. Servir las imágenes pequeñas individualmente será mejor en muchos casos; solo necesitará servir lo que se requiere para la página en la que se encuentra el visitante. La creación de un sprite seguirá estando justificada en algunos casos; Las solicitudes HTTP son solo un aspecto del rendimiento. La combinación de algunas imágenes en un sprite podría lograr una mejor compresión y, por lo tanto, un tamaño de descarga más pequeño en general, especialmente si todas esas imágenes se usan en la página que se está cargando. Sin embargo, ya no será el caso de que un sprite sea siempre la mejor opción.

Insertar imágenes usando URI de datos

Otra solución para el problema de múltiples solicitudes HTTP en HTTP/1.1 es insertar imágenes en CSS usando URI de datos. Incrustar imágenes de esta manera hará que la hoja de estilo sea mucho más grande. Si ha combinado esto con otra técnica de optimización para concatenar activos, es probable que un visitante descargue todo este código incluso si nunca visita las páginas donde se usan las imágenes.

Dado que las solicitudes HTTP son muy baratas en HTTP/2, esta "mejor práctica" obstaculizará el rendimiento en lugar de ayudar.

Concatenando CSS y JavaScript

Como paso final en nuestro proceso de creación, muchos de nosotros concatenaremos todos los pequeños archivos CSS y JavaScript utilizados en nuestro sitio web. A menudo queremos mantenerlos separados durante el desarrollo para que sea más fácil administrar estos recursos, pero sabemos que entregar un archivo al navegador es más eficiente para el rendimiento que entregar cinco. Una vez más, estamos tratando de limitar las solicitudes HTTP.

Si está haciendo esto, entonces un visitante que llega a su página de inicio puede descargar todo el CSS y JavaScript requerido para su sitio web, incluso si nunca usa la mayor parte. Como desarrollador, puede solucionar este problema seleccionando cuidadosamente e incluyendo archivos específicos para cada área del sitio web en su proceso de creación, pero eso puede ser bastante trabajo.

Un problema adicional con la concatenación es que todo deberá eliminarse de la memoria caché a la vez. No puede asignar una fecha de caducidad prolongada a algunos archivos que nunca cambian y, al mismo tiempo, asignar una fecha más corta a partes del código base que cambian con frecuencia. Todo tiene que caducar si se cambia incluso una línea de CSS, utilizada en una sola página.

¡Me imagino que ves a dónde va esto! Las solicitudes HTTP son baratas en el mundo de HTTP/2 . Organizar sus activos durante el desarrollo según las páginas en las que se utilizarán será mucho mejor. A continuación, puede servir solo el código que necesita el visitante. Descargar muchas hojas de estilo diminutas no importará. También puede organizar en función de la frecuencia con la que cambian las cosas; los activos con longevidad podrían entonces ser cuidados por más tiempo.

Dividir recursos entre hosts: fragmentación

Con HTTP/1.1, está restringido al número de conexiones abiertas. Si es inevitable cargar una gran cantidad de recursos, un método para sortear esta restricción es recuperarlos de varios dominios. Esto se conoce como fragmentación de dominio. Esto puede lograr mejores tiempos de carga, pero puede causar problemas en sí mismo, sin mencionar la sobrecarga de desarrollo de preparar esto para su sitio web.

HTTP/2 elimina esta necesidad de fragmentación del dominio porque puede solicitar tantos recursos como necesite. De hecho, es probable que esta técnica perjudique el rendimiento porque crea conexiones TCP adicionales e impide que HTTP/2 priorice los recursos.

Cómo prepararse para HTTP/2 ahora

Si está iniciando un proyecto que espera que tenga cierta longevidad pero no puede ejecutar HTTP/2 quizás debido al soporte del servidor, valdría la pena considerar cómo puede prepararse para HTTP/2. Puede agregar algunas cosas a su proceso de compilación ahora que facilitarán el cambio más adelante.

Cree activos individuales además de sprites y URI de datos

Si está creando sprites, agregue a su proceso la creación y optimización de esos activos individuales también, o sprites específicos de página más pequeños si cree que el rendimiento mejoraría mejor con estos. Esto le facilitará el cambio de sprites grandes a sprites pequeños (o ninguno) cuando se alcance el punto de inflexión para su sitio web.

Lo mismo es cierto para los URI de datos. Si actualmente los está usando en su CSS, tenga las imágenes listas para cuando cambie de esta técnica.

Organice sus activos por sección del sitio web

Con la concatenación de CSS y JavaScript, existe la tentación de optimizar para facilitar el desarrollo porque todos los archivos se aplastarán de todos modos. Cuando cambie a HTTP/2, obtendrá el mejor rendimiento administrando cuidadosamente los recursos para que solo se entreguen a esa página las cosas que necesita una determinada página. Por lo tanto, comenzar a organizar su desarrollo de esta manera ahora valdrá la pena. Por ahora, aún puede concatenar, y cuando se alcance el punto de inflexión, puede detener esa parte de su proceso de compilación y servir los recursos individualmente.

Administrar fragmentos de dominio

La mejor práctica actual para HTTP/1.1 es limitar la fragmentación a dos nombres de host. Hay una forma de obtener HTTP/2 para fusionar las conexiones, si el certificado TLS es válido para ambos hosts y los hosts se resuelven en la misma IP. Dado que los implementadores de navegadores requieren que HTTP/2 se ejecute sobre HTTPS, es necesario que el certificado TLS se ejecute sobre HTTP/2. Vea más en la diapositiva 26 de la plataforma de diapositivas de Ilya Grigorik de la Conferencia Velocity.

Más por venir

En última instancia, obtendremos una gran cantidad de mejores prácticas para HTTP/2. Para obtener el mejor rendimiento, este protocolo le devolverá mucho control, lo que significa que deberá tomar decisiones para cada proyecto. No he cubierto en este artículo cómo aprovechar las nuevas funciones de HTTP/2, como la inserción del servidor. Esta tecnología le permite decidir qué recursos son prioritarios e instruye al servidor para que los entregue antes que cosas menos importantes.

¿Cuándo cambiar?

Para los diseñadores y desarrolladores que no tienen control total sobre los servidores en los que implementan, es posible que la decisión deba esperar hasta que se actualicen los servidores que usan. Hay empresas de alojamiento que ya ofrecen HTTP/2, incluso para alojamiento compartido, por lo que la implementación en un servidor compatible es algo que podría recomendar a un cliente si sabe que se beneficiaría.

Una vez que su sitio web esté alojado en un servidor compatible con HTTP/2, la decisión de continuar optimizando para HTTP/1.1 u optimizar para HTTP/2 dependerá del protocolo compatible con la mayoría de sus usuarios . Recuerde que HTTP/2 es compatible con versiones anteriores; no necesita hacer nada específico. La decisión que debe tomar es cuándo optimizar para ello.

Deberá decidir de acuerdo con sus datos analíticos. Si hay más visitantes que no usan navegadores compatibles con HTTP/2, entonces sugiero que es un punto de inflexión razonable para optimizar para esos usuarios. Muchos de nosotros ya habremos llegado a ese punto. Debe usar datos de sitios como Can I Use junto con datos recopilados de su propio análisis y conocimiento de su audiencia probable. Por ejemplo, muchos de los beneficios de HTTP/2 los sentirán más profundamente los usuarios de dispositivos móviles compatibles con HTTP/2. Si tiene un alto porcentaje de tráfico móvil, podría ser una indicación para cambiar a HTTP/2 antes. Sin embargo, si tiene un alto porcentaje de tráfico móvil de usuarios que navegan usando Opera Mini, esa sería una razón para posponer el cambio a HTTP/2, ya que actualmente no tiene soporte y tiene una gran cantidad de usuarios en algunos. partes del mundo.

Si está creando un sitio web completamente nuevo hoy, le sugiero que tenga en cuenta la optimización de HTTP/2 a lo largo de su creación. Si en el lanzamiento, siente que necesita hacer concesiones para HTTP/1.1 debido a la compatibilidad con el navegador o el servidor, mucho de eso se puede hacer en el proceso de compilación, lo que le permite cambiar a la versión HTTP/2 tan pronto como lo sienta. el tiempo es correcto

Su plan de acción HTTP/2

1. Inicie con una conexión segura o cambie a TLS ahora Esta debería ser su prioridad.
2. Prepárese para HTTP/2 en su proceso de compilación. Cualquier sitio web que construya ahora probablemente se beneficiaría de la optimización para HTTP/2 durante su vida útil. Utilice los consejos anteriores para crear un proceso de compilación que se pueda optimizar para ambos protocolos.
3. Consulta tus estadísticas. Al comparar el uso del navegador en su sitio web con la tabla de soporte en Can I Use, puede ver qué porcentaje de visitantes se beneficiaría de la optimización HTTP/2.
4. Consulta tu alojamiento. Cuando llegue al punto en el que se beneficiaría del cambio, deberá asegurarse de que su servidor sea compatible con HTTP/2. Hable con su proveedor de alojamiento o administrador del servidor para conocer su plan de migración.
5. Implemente la optimización de HTTP/2. Una vez que su servidor admita HTTP/2, el resto depende de usted. Deje de usar las viejas mejores prácticas y cambie a las nuevas. Esto significará que los usuarios con navegadores que no admiten HTTP/2 obtendrán una experiencia más lenta, razón por la cual el impulsor detrás de su cambio debería ser el punto de inflexión cuando la mayoría se beneficiaría.

Cuando cambie a HTTP/2, sería interesante comparar los aumentos de velocidad y ver qué técnicas han marcado las mayores diferencias en sus sitios web. Espero ver información de casos del mundo real a medida que las personas migren sitios web. Esa información nos ayudará a desarrollar toda una nueva generación de mejores prácticas.

Saber más

Una cantidad cada vez mayor de información sobre HTTP/2 está disponible en línea. He enumerado algunos recursos aquí para su referencia, muchos de los cuales mencioné mientras escribía este artículo.

• “Protocolo de transferencia de hipertexto versión 2 (HTTP/2)” (especificación), Grupo de Trabajo de Ingeniería de Internet Esto es para personas que disfrutan leyendo especificaciones o que necesitan entender los puntos más finos. Para todos los demás, las preguntas frecuentes de HTTP/2 son un excelente resumen de las características principales.
• http2 explicó , Daniel Sternberg Vale la pena leer este libro electrónico gratuito si desea profundizar en los detalles del protocolo mientras planifica su estrategia.
• Redes de navegador de alto rendimiento , Ilya Grigorik, O'Reilly Este libro cubre las mejores prácticas de HTTP/1.1 y HTTP/2. Sería útil para cualquiera que quiera mejorar el rendimiento hoy y prepararse para el futuro.
• "HTTP/2 está aquí, vamos a optimizar" (slidedeck) Ilya Grigorik Este excelente conjunto de diapositivas tiene más información sobre algunos de los puntos tratados en este artículo.
• Indicador HTTP/2: Firefox y Chrome Este complemento de navegador le indica si el sitio web en el que se encuentra está siendo atendido a través de HTTP/2.
• Para obtener más información, consulte esta enorme lista de enlaces seleccionada por Rebecca Murphey.