Hoy nos emociona anunciar la disponibilidad de HTTP/2 en el Hosting de Firebase. HTTP/2 es una nueva versión del protocolo HTTP que ya es compatible con el 77 % de todos los navegadores a nivel mundial. Ofrece interesantes ventajas para los desarrolladores web:
  • Se pueden enviar múltiples solicitudes en una sola conexión. Con HTTP/2, la necesidad de concentrar recursos es menor.
  • Es un protocolo binario, lo que significa que los títulos se pueden comprimir y los datos se pueden enviar eficientemente.
  • Los servidores pueden "empujar" contenido a los clientes.

En conjunto, estas ventajas se suman a otras ventajas significativas de rendimiento y a muchas oportunidades para que tus aplicaciones web carguen más rápido en los dispositivo móviles con conexiones lentas.

Actualmente HTTP/2 está habilitado para todo el tráfico de *.firebaseapp.com y los dominios personalizados que sean provisionados recientemente. Si ya tienes un dominio personalizado en Firebase, mira Migración de dominios personalizados abajo.

Ventajas de HTTP/2 en el Hosting de Firebase


Para utilizar HTTP/2 en el Hosting de Firebase, ¡no tienes que hacer nada! Funcionará automáticamente si es compatible con el navegador del usuario. Sin embargo, existen algunas buenas prácticas que debes tener en cuenta si quieres optimizar para HTTP/2:
  1. Dado que se puede usar una sola conexión para varias solicitudes múltiples, ya no existe una ventaja en concatenar gran cantidad de recursos juntos. Dado que los navegadores hacen un buen trabajo a la hora de almacenar recursos, es mejor servir más archivos que no cambien de manera frecuente. Ten en cuenta que cuando nos referimos a más archivos, queremos decir decenas, ya que cientos pueden significar un exceso.
  2. Ya no es necesario (o deseable) "dividir" activos entre muchos dominios. El Hosting de Firebase ya es servido en una CDN rápida y HTTP/2 hace que sea una ventaja servir todos tus archivos desde el mismo dominio.
  3. ¡Solo carga los activos que necesites! Con menos viajes, deberías optimizar tu sitio para que cargue únicamente los archivos que necesitas para impulsar el armazón de tu aplicación. Se pueden cargar otros recursos en demanda con base a la interacción del usuario.

Las guías presentadas anteriormente no son normas rígidas. Como ocurre con cualquier optimización de rendimiento, debes experimentar con diferentes combinaciones de optimizaciones para ver cuáles ofrecen el mejor resultado para las necesidades específicas de tu aplicación.

Experimentar con el Servidor Push


El Hosting de Firebase cuenta con una compatibilidad experimental para el servidor push de HTTP/2 que usa encabezados de vínculo. El servidor push permite al servidor enviar automáticamente los contenidos para recursos adicionales cuando se hace una solicitud inicial. El uso más común para el servidor push es enviar activos asociados (como archivos JavaScript o CSS) cuando se carga una página.

Para configurar el servidor push en el Hosting de Firebase, necesitas agregar el encabezado de vínculo en tu configuración firebase.json así: 
{
  "hosting": {
    "headers": [
      {
        "source": "/",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style"}]
      },
      {
         "source": "/users/*",
        "headers": [{"key": "Link", "value": "</js/app.js>;rel=preload;as=script,</css/app.css>;rel=preload;as=style;nopush,</css/users.css>;rel=preload;as=style"}]
      }
    ]
  }
}

Aquí estamos usando el servidor push para precargar /js/app.js y /css/app.css en la ruta de acceso, y /css/users.css en cualquier ruta de acceso que corresponda con /users/*. Puedes usar la directiva nopush (como en app.css en el segundo ejemplo) para precargar el activo sin que HTTP/2 envíe los archivos que probablemente ya estén en la memoria caché del navegador.

El servidor push aún está en una etapa temprana y hay algunas cosas que hay que tener en cuenta:
  1. Ten cuidado con el comodín al configurar los encabezados de vínculo. Los recursos no se deben configurar para que se precarguen ellos mismos.
  2. El servidor push es una compensación entre el rendimiento y el uso del ancho de banda. Si envías activos que ya están en la memoria caché del navegador, estarás enviando información innecesaria. Intenta que los activos enviados sean pequeños, que sean críticos para el rendimiento y ten en cuenta que ¡es posible que tus usuarios tengan que pagar por los datos adicionales en sus dispositivos móviles!.
  3. ¡Precargar es muy bueno para el rendimiento incluso si no se envía! Si agregas ;nopush a tu encabezado de vínculo precargado, le dirá al navegador que lo precargue sin el servidor push. Esto es genial para los activos que consideres que ya pueden estar en la memoria caché del navegador.

Estamos emocionados por el potencial de HTTP/2 para mejorar la experiencia de la primera carga, y continuamos explorando formas adicionales para que el servidor push sea simple, confiable y efectivo para tu sitio.

Migración al Dominio personalizado


Con nuestra migración a HTTP/2 también nos estamos moviendo a la Indicación del nombre del servidor (SNI, por sus siglas en inglés) para nuestros certificados SSL. SNI nos permite continuar con el crecimiento de nuestra infraestructura de una manera confiable y es compatible con cerca del 98 % de los navegadores a nivel mundial. Dado que este cambio tiene la posibilidad de afectar el tráfico del usuario, no estamos cambiando automáticamente en los dominios personalizados existentes hasta diciembre de 2016.

Si tienes un dominio personalizada en el Hosting de Firebase antes de agosto 11 de 2016, necesitarás actualizar tus registros DNS para aprovechar el HTTP/2. Puedes verificar si ya estás en SNI ejecutando dig <your-site>.firebaseapp.com. Si ves s-sni.firebaseapp.com en el resultado, tu sitio ya migró.

Para migrar si estás usando un CNAME, actualiza tu DNS para que se dirija a s-sni.firebaseapp.com. Si usas registros A, actualízalos a: 
151.101.1.195
151.101.65.195

Una vez que cambies tu DNS y se haya propagado, ¡tu sitio estará vivo usando HTTP/2! Estaremos en un proceso de transición del trafico del Hosting de Firebase a HTTP/2 y SNI hasta el final del año, por lo tanto busca asesoría si estás preocupado sobre cómo la SNI puede afectar a tus usuarios.

Nuestro objetivo con el Hosting de Firebase es que las mejores prácticas para el desarrollo de las aplicaciones web progresivas estén al alcance de todos. HTTP/2 es otro paso en el camino, ¡y nos gustaría saber los que puedes construir con éste!