Cargas más rápidas de páginas utilizando el tiempo de reflexión del servidor con Sugerencias iniciales.

Descubre cómo tu servidor puede enviar sugerencias al navegador sobre subrecursos críticos.

Kenji Baheux

Barry Pollard

¿Qué es Sugerencias anticipadas?

Los sitios web se han vuelto más sofisticados con el tiempo. Por lo tanto, no es inusual que un servidor deba realizar un trabajo importante (por ejemplo, acceso a bases de datos o CDN que acceden al servidor de origen) para producir el código HTML de la página solicitada. Lamentablemente, este “tiempo de reflexión del servidor” genera latencia adicional antes de que el navegador pueda comenzar a renderizar la página. De hecho, la conexión quedará inactiva durante el tiempo que el servidor tarde en preparar la respuesta.

Early Hints es un código de estado HTTP (103 Early Hints) que se usa para enviar una respuesta HTTP preliminar antes de una respuesta final. Esto permite que un servidor envíe sugerencias al navegador sobre subrecursos críticos (por ejemplo, hojas de estilo para la página o JavaScript crítico) u orígenes que probablemente utilizará la página, mientras el servidor está ocupado generando el recurso principal. El navegador puede usar esas sugerencias para preparar conexiones y solicitar subrecursos mientras espera el recurso principal. En otras palabras, Early Hints ayuda al navegador a aprovechar ese "tiempo de reflexión del servidor" al realizar algunas tareas por adelantado, lo que acelera la carga de páginas.

En algunos casos, la mejora del rendimiento del Largest Contentful Paint puede demorar de varios cientos de milisegundos, como observan Shopify y Cloudflare, y hasta un segundo más rápido, como se observa en esta comparación antes y después:

Cómo usar Sugerencias iniciales

El primer paso para aprovechar las Sugerencias iniciales consiste en identificar las páginas de destino principales, es decir, las páginas en las que los usuarios suelen comenzar cuando visitan tu sitio web. Podría ser la página principal o las páginas populares de fichas de productos si tienes muchos usuarios que provienen de otros sitios web. El motivo por el que estos puntos de entrada son más importantes que otras páginas es que la utilidad de Early Hints disminuye a medida que el usuario navega por tu sitio web (es decir, es más probable que el navegador tenga todos los subrecursos que necesita en la segunda o tercera navegación posterior). ¡Siempre es una buena idea dar una buena primera impresión!

Ahora que tienes esta lista priorizada de páginas de destino, el siguiente paso es identificar qué orígenes o subrecursos serían buenos candidatos para las sugerencias de preconnect o preload. Por lo general, serían los orígenes y subrecursos que más contribuyen a las métricas clave del usuario, como Largest Contentful Paint o First Contentful Paint. De manera más concreta, busca subrecursos que bloqueen el procesamiento, como JavaScript síncrono, hojas de estilo o incluso fuentes web. De manera similar, busca orígenes que alojen subrecursos que contribuyan mucho a las métricas clave del usuario.

Además, ten en cuenta que, si tus recursos principales ya usan preconnect o preload, puedes considerar esos orígenes o recursos entre los candidatos para las sugerencias tempranas. Consulta cómo optimizar el LCP para obtener más detalles. Sin embargo, copiar de forma simple las directivas preconnect y preload de HTML a Sugerencias iniciales puede no ser óptimo.

Cuando se usan en HTML, lo más recomendable es usar recursos preconnect o preload que Preload Scanner no descubrirá en HTML; por ejemplo, fuentes o imágenes de fondo que, de otro modo, se descubrirían tarde. En el caso de Sugerencias tempranas, no tendrás el código HTML. En su lugar, te recomendamos preconnect dirigir a dominios críticos o preload recursos críticos que tal vez podrían descubrirse al principio del código HTML, por ejemplo, durante la carga previa de main.css o app.js. Además, no todos los navegadores admiten preload para Sugerencias anticipadas. Consulta Compatibilidad con navegadores.

El segundo paso consiste en minimizar el riesgo de usar sugerencias anticipadas en orígenes o recursos que podrían quedar obsoletos o que el recurso principal ya no los use. Por ejemplo, es posible que los recursos que se actualizan y controlan versiones con frecuencia (por ejemplo, example.com/css/main.fa231e9c.css) no sean la mejor opción. Ten en cuenta que este problema no es específico de las sugerencias anticipadas, sino que se aplica a cualquier preload o preconnect, siempre que estén presentes. Este es el tipo de detalle que mejor se aborda con la automatización o las plantillas (por ejemplo, es más probable que un proceso manual genere discrepancias en las URLs o el hash de la versión entre preload y la etiqueta HTML real que usa el recurso).

Como ejemplo, considera el siguiente flujo:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

El servidor predice que se necesitará main.abcd100.css y sugiere precargarlo con Early Hints:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Después de un momento, se publica la página web, incluido el CSS vinculado. Lamentablemente, este recurso de CSS se actualiza con frecuencia, y el recurso principal ya tiene cinco versiones por delante (abcd105) del recurso de CSS previsto (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

En general, apunta a recursos y orígenes que sean bastante estables y que, en gran medida, sean independientes del resultado del recurso principal. Si es necesario, puedes considerar dividir tus recursos clave en dos: una parte estable diseñada para usarse con Early Hints y una parte más dinámica que se puede recuperar después de que el navegador recibe el recurso principal:

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Por último, en el servidor, busca las solicitudes de recursos principales que envían los navegadores conocidos por admitir Early Hints y responde de inmediato con 103 Early Hints. En la respuesta 103, incluye las sugerencias relevantes de preconexión y precarga. Una vez que el recurso principal esté listo, realiza un seguimiento con la respuesta habitual (por ejemplo, 200 OK si se ejecuta correctamente). Para ofrecer retrocompatibilidad, se recomienda incluir también encabezados HTTP Link en la respuesta final, tal vez incluso aumentarlos con recursos críticos que se hicieron evidentes como parte de la generación del recurso principal (por ejemplo, la parte dinámica de un recurso de clave si seguiste la sugerencia de "dividir en dos"). Así es como se vería:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Después de un momento:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Navegadores compatibles

Aunque 103 Early Hints es compatible con todos los navegadores principales, las directivas que se pueden enviar en Early Hint difieren según el navegador:

Compatibilidad con la preconexión:

Compatibilidad con la precarga:

Las Herramientas para desarrolladores de Chrome también tienen compatibilidad con 103 Early Hints.

Asistencia para servidores

A continuación, se incluye un breve resumen del nivel de compatibilidad con Early Hints entre el software de código abierto popular del servidor HTTP:

• Apache: Es compatible con mod_http2.
• H2O: Es compatible.
• NGINX: Módulo experimental.
• Nodo: compatible a partir de la versión 18.11.0 para http y http2

Habilita Early Hints de la manera más sencilla

Si usas una de las siguientes CDN o plataformas, es posible que no necesites implementar las sugerencias anticipadas de forma manual. Consulta la documentación en línea de tu proveedor de soluciones para saber si admite las sugerencias iniciales o consulta la lista no exhaustiva aquí:

• Sugerencias iniciales para Cloudflare
• Sugerencias anticipadas de Fastly.
• Sugerencias anticipadas en Akamai.

Cómo evitar problemas para clientes que no admiten Sugerencias anticipadas

Las respuestas HTTP informativas en el rango 100 son parte del estándar HTTP, pero algunos clientes o bots más antiguos pueden tener dificultades con estas porque, antes del lanzamiento de 103 Early Hints, rara vez se usaban para la navegación web general.

La emisión de sugerencias tempranas 103 en respuesta a clientes que envían un encabezado de solicitud HTTP sec-fetch-mode: navigate debe garantizar que estas sugerencias solo se envíen para clientes más nuevos que comprendan que deben esperar la respuesta posterior. Además, dado que las sugerencias anticipadas solo se admiten en las solicitudes de navegación (consulta las limitaciones actuales), esta opción tiene el beneficio adicional de evitar enviarlas de forma innecesaria en otras solicitudes.

Además, se recomienda enviar las sugerencias tempranas solo a través de conexiones HTTP/2 o HTTP/3.

Patrón avanzado

Si aplicaste por completo las sugerencias tempranas a tus páginas de destino clave y buscas más oportunidades, es posible que te interese el siguiente patrón avanzado.

En el caso de los visitantes que acceden a la nth solicitud de página como parte de un recorrido típico del usuario, recomendamos que adaptes la respuesta de Sugerencias anticipadas al contenido que se encuentra cada vez más abajo en la página, es decir, usando Sugerencias tempranas en recursos de menor prioridad. Esto puede sonar contradictorio, ya que recomendamos enfocarse en orígenes o subrecursos de alta prioridad que bloqueen la renderización. Sin embargo, para cuando un visitante navegue durante un tiempo, es muy probable que su navegador ya tenga todos los recursos críticos. A partir de ahí, podría tener sentido dirigir tu atención hacia los recursos de menor prioridad. Por ejemplo, esto podría significar usar Sugerencias anticipadas para cargar imágenes de productos o JS/CSS adicionales que solo se necesitan para interacciones menos comunes de los usuarios.

Limitaciones actuales

Estas son las limitaciones de las sugerencias anticipadas que se implementaron en Chrome:

• Solo está disponible para las solicitudes de navegación (es decir, el recurso principal del documento de nivel superior).
• Solo admite preconnect y preload (es decir, prefetch no es compatible).
• Si usas una sugerencia temprana seguida de un redireccionamiento de origen cruzado en la respuesta final, Chrome perderá los recursos y las conexiones que obtuvo con las sugerencias tempranas.

Otros navegadores tienen limitaciones similares y algunos restringen aún más las primeras sugerencias 103 solo a preconnect.

¿Qué sigue?

Según el interés de la comunidad, es posible que mejoremos nuestra implementación de Sugerencias iniciales con las siguientes capacidades:

• Sugerencias anticipadas que se envían en las solicitudes de subrecursos
• Se envían sugerencias anticipadas en las solicitudes de recursos principales de iframe.
• Compatibilidad con la carga previa en Early Hints.

Agradecemos tus comentarios sobre los aspectos que debes priorizar y sobre cómo mejorar aún más las sugerencias tempranas.

Relación con H2 y Push

Si conoces la función de HTTP2/Push obsoleta, es posible que te preguntes en qué se diferencian las sugerencias tempranas. Si bien Early Hints requiere un proceso de ida y vuelta para que el navegador comience a recuperar subrecursos críticos, con HTTP2/Push el servidor podría empezar a enviar subrecursos junto con la respuesta. Aunque esto suena increíble, esto generó una desventaja estructural clave: con HTTP2/Push era extremadamente difícil evitar empujar subrecursos que el navegador ya tenía. Este efecto de “impulsión excesiva” dio como resultado un uso menos eficiente del ancho de banda de la red, lo que entorpeció de manera significativa los beneficios de rendimiento. En general, los datos de Chrome mostraron que HTTP2/Push, de hecho, era un valor negativo en el rendimiento en toda la Web.

Por el contrario, Early Hints funciona mejor en la práctica, ya que combina la capacidad de enviar una respuesta preliminar con pistas que dejan al navegador a cargo de buscar o conectarse con lo que realmente necesita. Si bien Early Hints no abarca todos los casos de uso que HTTP2/Push podrían abordar en teoría, creemos que Early Hints es una solución más práctica para acelerar las navegaciones.

Imagen en miniatura de Pierre Bamin.