Los sitios todavía se están cargando muy lentamente. En el momento más crítico del proceso de descarga, el canal a menudo está casi completamente inactivo. La nueva tecnología de Fastly, propuesta por el ingeniero Kazuho Oku, ayudará a hacer un mejor uso de estos primeros segundos críticos.

¿Alguna vez ha descargado un sitio web en su teléfono y buscó durante 10 segundos en una página sin texto? A nadie le gusta sentarse y mirar una pantalla en blanco mientras se carga una fuente inusual. Por lo tanto, tiene sentido transferir la carga de cosas tan importantes al tiempo más temprano posible. Se suponía que el enlace de precarga rel = preload resolvería parcialmente el problema. Primero, el navegador analiza los encabezados HTTP, por lo que este es el lugar perfecto para apuntar a precargar un recurso que definitivamente necesitará más adelante.

Por defecto, Internet es lento

Veamos qué sucede si no usas preload. El navegador solo puede comenzar a cargar recursos después de descubrir que los necesita. Es más probable que esto suceda para los recursos que están en HTML durante el análisis inicial del documento (por ejemplo, <script> , <link rel=stylesheet> y <img> ).

Los recursos que se detectan después de construir el árbol de renderizado se descargan más lentamente (este es el lugar donde la página se ralentiza debido a la carga de la fuente, porque para comprender esto, primero debe cargar la hoja de estilo, analizarla, construir el modelo de objetos CSS y luego el árbol de renderizado).

Aún más lento son los recursos de carga que se agregan al documento utilizando cargadores de JavaScript que se desencadenan por eventos como DOMContentLoaded . Si pone todo junto, obtenemos una cascada no optimizada y sin sentido. La mayoría de las veces el canal está inactivo y los recursos se cargan antes de lo necesario o demasiado tarde:

Enlace rel = preload ayuda mucho

En los últimos años, la situación ha mejorado gracias a Link rel = preload . Por ejemplo:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

Gracias a estas directivas, el navegador puede comenzar a cargar recursos inmediatamente después de recibir los encabezados y antes de comenzar el análisis del cuerpo HTML:



Esta es una mejora significativa, especialmente para páginas grandes y recursos críticos que de otro modo se descubrirían tarde. Especialmente para las fuentes, pero cualquier cosa puede convertirse en un recurso crítico, como el archivo de datos necesario para cargar una aplicación JavaScript.

Sin embargo, podemos hacer más. Después de todo, el navegador no hace nada entre el momento en que termina de enviar la solicitud y cuando recibe los primeros bytes de la respuesta (el fragmento verde grande en la solicitud inicial es mayor).

Utilizamos el tiempo de "pensamiento de servidor" con la ayuda de "consejos tempranos"

Por otro lado, el servidor está realmente ocupado. Genera una respuesta y determina si tiene éxito o no. Después de acceder a la base de datos, llamadas API, autenticación, etc. el servidor puede decidir que el error 404 es la respuesta correcta.

A veces, el tiempo de meditación del servidor es menor que la latencia de la red. A veces sustancialmente más. Pero es importante entender que no se superponen. Mientras el servidor está pensando, no estamos enviando datos al cliente.

Pero es interesante que incluso antes de generar la respuesta, ya conozca algunos estilos y fuentes que necesita descargar para mostrar la página. Después de todo, las páginas de error generalmente usan la misma identidad corporativa y diseño que las páginas normales. Sería genial enviar estos Link: rel=preload antes de que el servidor funcione . Es por eso que el estándar Early Hints , concebido en RFC8297 por el Grupo de Trabajo HTTP, fue acuñado por Fastly, mi colega Kazuho Oku. Evalúa la magia de múltiples barras de estado en una respuesta :

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

El servidor puede registrar el primer código de respuesta denominado "informativo" , tan pronto como recibe una solicitud, y enviarlo a la red. Luego se ocupará de la definición de una reacción real y su generación. Mientras tanto, en el navegador, puede comenzar a precargar mucho antes:



Por supuesto, esto requerirá ciertos cambios en el funcionamiento de los navegadores, servidores y CDN, y los desarrolladores de algunos navegadores han expresado reservas sobre las dificultades de implementación. Por lo tanto, todavía no está claro cuándo se pueden poner en funcionamiento estos encabezados. Puede seguir el progreso en rastreadores públicos para Chrome y Firefox .

Esperamos que, al final, pueda emitir encabezados Early Hints directamente desde Fastly, aún enviando solicitudes de manera estándar. Todavía no hemos decidido cómo configurar la interfaz a través de VCL, así que avíseme si tiene algún deseo sobre este tema.

Pero, ¿qué pasa con HTTP / 2 Server Push?

Con HTTP / 2, hay una nueva tecnología llamada Server Push que parece resolver el mismo problema que Link rel = preload en la respuesta Early Hints. Aunque realmente funciona (e incluso puede generar rápidamente una inserción personalizada desde los servidores perimetrales en Fastly), existen diferencias significativas en varios puntos:

• El servidor no conoce la disponibilidad de un recurso en el cliente, por lo que a menudo lo empuja innecesariamente. Debido a la memoria intermedia y la latencia de la red, el cliente generalmente no puede cancelar el envío antes de recibir todo el contenido. (Aunque hay una posible solución a este problema, en la forma del encabezado Cache Digest propuesto, en el que Kazuho está trabajando con Joam Weiss de Akamai).
• Los recursos transmitidos están vinculados a la conexión, por lo que es fácil iniciar un recurso que el cliente no utiliza, ya que está intentando obtenerlo a través de otra conexión. Es posible que los clientes necesiten usar una conexión diferente porque el recurso está en una fuente diferente con un certificado TLS diferente o porque se recupera en un modo de credencial diferente.
• H2 Push no se implementa de manera muy consistente en diferentes navegadores. Por lo tanto, es difícil predecir si funcionará o no en su caso particular.

De una forma u otra, Early Hints y Server Push ofrecen diferentes compensaciones. Las primeras sugerencias proporcionan un uso más eficiente de la red a cambio de intercambios de paquetes adicionales. Si espera una latencia de red pequeña y mucho tiempo para pensar en el servidor, Early Hints es la solución correcta.

Sin embargo, este no es siempre el caso. Seamos optimistas e imaginemos que la gente pronto se asentará en Marte. Navegarán por la web con un retraso de 20-45 minutos para cada intercambio de paquetes, por lo que el intercambio adicional es extremadamente doloroso y el tiempo del servidor es insignificante en comparación con él. Server Push gana fácilmente aquí. Pero si alguna vez miramos páginas web de Marte, es más probable que descarguemos algún tipo de paquete de datos, algo así como paquetes web que ahora se ofrecen e intercambios firmados .

Bono adicional: colapso de solicitud más rápido

Aunque se supone que Early Hints se usa principalmente en el navegador, hay un beneficio potencial interesante para CDN. Cuando Fastly recibe muchas solicitudes para el mismo recurso, generalmente enviamos solo una de ellas a la fuente y ponemos el resto en la cola de espera. Este proceso se conoce como colapso de solicitudes . Si la respuesta de la fuente incluye Cache-Control: private , debe eliminar todas las solicitudes de la cola y enviarlas por separado a la fuente, porque no podemos usar una respuesta para satisfacer varias solicitudes.

No podemos tomar una decisión hasta que se reciba una respuesta a la primera solicitud, pero en el caso del soporte de Early Hints, si el servidor devolvió una respuesta de Early Hints con el encabezado Cache-Control, sabremos mucho antes que la cola no puede colapsarse en una sola solicitud, sino que en su lugar reenvíe inmediatamente todas las solicitudes de la cola a la fuente.

Ordene contenido menos crítico con consejos prioritarios

Los primeros consejos son una excelente manera de acceder a algunos de los objetos más valiosos de la cola (cascada): cuando la red está inactiva, el usuario espera, solo hay una solicitud en el camino y no hay nada en la pantalla. Pero tan pronto como se carga el HTML y se analiza la página, la cantidad de recursos que deben cargarse aumenta drásticamente. Ahora es importante no cargar recursos lo más rápido posible, sino cargarlos en el orden correcto. Los navegadores utilizan un conjunto sorprendentemente complejo de heurísticas para determinar de forma independiente la prioridad de la descarga, pero si desea redefinirlos, en el futuro esto se puede hacer utilizando Sugerencias de prioridad :

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

Con este nuevo atributo de importancia, los desarrolladores pueden controlar el orden de carga de los recursos en caso de competencia por la red. Quizás los recursos de baja prioridad se puedan retrasar hasta que el procesador y la red estén libres, o dependiendo del tipo de dispositivo.

¿Se puede usar esto?

Ni las primeras pistas ni las pistas prioritarias se han convertido en el estándar todavía. Recientemente, H2O, el servidor HTTP / 2 utilizado y respaldado por Fastly, comenzó a usar Early Hints (ver PR 1727 y 1767 ), y existe la intención de implementar Priority Hints en Chrome , así como rastrear activamente las respuestas 1xx. Al mismo tiempo, no hay nada de malo en comenzar a enviar Early Hints en este momento, y si quiere adelantarse a la tendencia, ¡vaya!