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é son las sugerencias iniciales?

Los sitios web se han vuelto más sofisticados con el tiempo. Por lo tanto, no es inusual que un servidor deba realizar tareas no triviales (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 pensamiento del servidor" genera latencia adicional antes de que el navegador pueda comenzar a procesar la página. De hecho, la conexión queda inactiva durante el tiempo que le lleve al servidor preparar la respuesta.

Los indicadores anticipados son 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, JavaScript crítico) o orígenes que probablemente usará la página, mientras el servidor está ocupado generando el recurso principal. El navegador puede usar esas sugerencias para activar las conexiones y solicitar subrecursos mientras espera el recurso principal. En otras palabras, las sugerencias anticipadas ayudan al navegador a aprovechar ese "tiempo de reflexión del servidor" realizando parte del trabajo con anticipación, lo que acelera la carga de páginas.

En algunos casos, la mejora del rendimiento de la pintura de contenido más grande puede ir de varios cientos de milisegundos, como observaron Shopify y Cloudflare, y hasta un segundo más rápido, como se ve en esta comparación antes y después:

Cómo usar los indicadores anticipados

El primer paso para aprovechar los indicadores anticipados consiste en identificar las páginas de destino principales, es decir, las páginas en las que tus usuarios suelen comenzar cuando visitan tu sitio web. Podría ser la página principal o páginas populares de fichas de productos si muchos usuarios provienen de otros sitios web. Estos puntos de entrada son más importantes que otras páginas porque 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). También es una buena idea causar 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 obtener sugerencias de preconnect o preload. Por lo general, esos serían los orígenes y subrecursos que más contribuyen a las métricas clave del usuario, como Procesamiento de imagen con contenido más grande o Primer procesamiento de imagen con contenido. Más concretamente, busca subrecursos que bloqueen la representación, como JavaScript síncrono, hojas de estilo o incluso fuentes web. Del mismo modo, busca orígenes que almacenen 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 estos orígenes o recursos entre los candidatos para las sugerencias anticipadas. Consulta cómo optimizar el LCP para obtener más detalles. Sin embargo, es posible que no sea óptimo copiar de forma ingenua las directivas preconnect y preload del HTML a los indicadores anticipados.

Cuando los usas en HTML, por lo general, se recomienda que preconnect o preload los recursos que el Prueba de precarga no descubra en el HTML; por ejemplo, fuentes o imágenes de fondo que, de lo contrario, se descubrirían tarde. En el caso de las sugerencias anticipadas, no tendrás el código HTML, por lo que te recomendamos que, en su lugar, preconnect a dominios críticos o preload a recursos críticos que, de otro modo, se descubrirían al principio del código HTML, por ejemplo, la carga previa de main.css o app.js. Además, no todos los navegadores admiten preload para las sugerencias anticipadas. Consulta la 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 use. Por ejemplo, es posible que los recursos que se actualizan con frecuencia y se controlan sus versiones (como example.com/css/main.fa231e9c.css) no sean la mejor opción. Ten en cuenta que esta inquietud no es específica de los indicadores anticipados, sino que se aplica a cualquier preload o preconnect dondequiera que estén presentes. Este es el tipo de detalle que se aborda mejor con la automatización o las plantillas (por ejemplo, es más probable que un proceso manual genere URLs de hash o de versión no coincidentes entre preload y la etiqueta HTML real que usa el recurso).

A modo de 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 sugerencias anticipadas:

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

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

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

En general, busca recursos y orígenes que sean bastante estables y, en gran medida, 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 los indicadores anticipados y una parte más dinámica que se recuperará después de que el navegador reciba 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 que se sabe que admiten los indicadores anticipados y responde de inmediato con 103 indicadores anticipados. En la respuesta 103, incluye las sugerencias de preconexión y carga previa relevantes. Una vez que el recurso principal esté listo, continúa con la respuesta habitual (por ejemplo, 200 OK si se realiza correctamente). Para la retrocompatibilidad, es recomendable incluir también encabezados HTTP Link en la respuesta final, incluso 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 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

Unos momentos más tarde:

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 los 103 indicadores anticipados son compatibles con todos los navegadores principales, las directivas que se pueden enviar en un indicador anticipado difieren según el navegador:

Compatibilidad con la conexión previa:

Asistencia para precarga:

Chrome DevTools también tiene compatibilidad con 103 Early Hints, y los encabezados Link se pueden ver en los recursos del documento:

Los encabezados de Link de sugerencias anticipadas se muestran en las Herramientas para desarrolladores de Chrome.

Ten en cuenta que, para usar los recursos de sugerencias anticipadas, no se debe marcar Disable cache en DevTools, ya que las sugerencias anticipadas usan la caché del navegador. En el caso de los recursos precargados, el iniciador se mostrará como early-hints y el tamaño como (Disk cache):

Esto también requiere un certificado de confianza para las pruebas de HTTPS.

Firefox (a partir de la versión 126) no tiene compatibilidad explícita con los 103 indicadores anticipados en DevTools, pero los recursos cargados con indicadores anticipados no muestran información del encabezado HTTP, que es un indicador de que se cargaron a través de los indicadores anticipados.

Asistencia para servidores

A continuación, se incluye un breve resumen del nivel de compatibilidad con los indicadores anticipados entre los servidores HTTP de software de código abierto populares:

• Apache: Es compatible con mod_http2.
• H2O: Compatible.
• NGINX: Módulo experimental.
• Node: Se admite desde la versión 18.11.0 para http y http2.

Habilita las sugerencias anticipadas de la manera más fácil

Si usas una de las siguientes CDN o plataformas, es posible que no debas implementar los indicadores anticipados de forma manual. Consulta la documentación en línea de tu proveedor de soluciones para saber si admite Early Hints o consulta la lista no exhaustiva que se encuentra aquí:

• Consejos iniciales de Cloudflare
• Sugerencias iniciales en Fastly.
• Sugerencias iniciales de Akamai.

Cómo evitar problemas para los clientes que no admiten sugerencias anticipadas

Las respuestas HTTP informativas en el rango 100 forman parte del estándar HTTP, pero es posible que algunos clientes o bots más antiguos tengan problemas con ellas porque, antes del lanzamiento de los indicadores anticipados 103, rara vez se usaban para la navegación web general.

Solo emitir 103 sugerencias anticipadas en respuesta a clientes que envían un encabezado de solicitud HTTP sec-fetch-mode: navigate debería garantizar que esas sugerencias solo se envíen a clientes más nuevos que comprendan que deben esperar la respuesta posterior. Además, dado que las sugerencias anticipadas solo se admiten en solicitudes de navegación (consulta las limitaciones actuales), esto tiene el beneficio adicional de evitar el envío innecesario de estos en otras solicitudes.

Además, se recomienda que las sugerencias anticipadas solo se envíen a través de conexiones HTTP/2 o HTTP/3, y la mayoría de los navegadores solo las aceptarán a través de esos protocolos.

Patrón avanzado

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

En el caso de los visitantes que están en su nª solicitud de página como parte de un recorrido típico del usuario, te recomendamos que adaptes la respuesta de los indicadores anticipados al contenido que está más abajo y más adentro de la página, es decir, que uses los indicadores anticipados en recursos de menor prioridad. Esto puede parecer contraintuitivo, ya que recomendamos enfocarse en subrecursos o orígenes de alta prioridad que bloquean la renderización. Sin embargo, para cuando un visitante haya navegado por un tiempo, es muy probable que su navegador ya cuente con todos los recursos críticos. A partir de ese momento, podría ser conveniente que cambies tu atención a 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 del usuario menos comunes.

Limitaciones actuales

Estas son las limitaciones de las Early Hints implementadas 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 se usan sugerencias anticipadas seguidas de un redireccionamiento entre orígenes en la respuesta final, Chrome descartará los recursos y las conexiones que obtuvo con las sugerencias anticipadas.
• Los recursos que se precargan con sugerencias anticipadas se almacenan en la caché HTTP y la página los recupera más adelante. Por lo tanto, solo los recursos que se pueden almacenar en caché se pueden precargar con Early Hints o el recurso se recuperará dos veces (una vez con Early Hints y otra vez por el documento). En Chrome, la caché HTTP está inhabilitada para los certificados HTTPS que no son de confianza (incluso si carga la página).
• La carga previa de imágenes responsivas (con imagesrcset, imagesizes o media) no es compatible con los encabezados HTTP <link>, ya que el viewport no se define hasta que se crea el documento. Esto significa que no se pueden usar los indicadores anticipados de 103 para precargar imágenes responsivas y es posible que se cargue la imagen incorrecta cuando se usen para esto. Siga este debate sobre propuestas sobre cómo abordar mejor esta situación.

Otros navegadores tienen limitaciones similares y, como se señaló anteriormente, algunos restringen aún más los 103 indicadores anticipados solo a preconnect.

Próximos pasos

Según el interés de la comunidad, es posible que aumentemos nuestra implementación de Early Hints con las siguientes funciones:

• Sugerencias anticipadas para recursos que no se pueden almacenar en caché con la caché de memoria en lugar de la caché de HTTP.
• Se enviaron sugerencias anticipadas en las solicitudes de subrecursos.
• Sugerencias anticipadas enviadas en solicitudes de recursos principales de iframe.
• Compatibilidad con la carga previa en los indicadores anticipados

Valoramos mucho tus comentarios sobre qué aspectos priorizar y cómo mejorar aún más los indicadores anticipados.

Relación con H2/Push

Si conoces la función HTTP2/Push obsoleta, es posible que te preguntes en qué se diferencian los indicadores anticipados. Si bien Early Hints requiere un recorrido de ida y vuelta para que el navegador comience a recuperar subrecursos críticos, con HTTP2/Push, el servidor podría comenzar a enviar subrecursos junto con la respuesta. Si bien esto suena increíble, tuvo un inconveniente estructural clave: con HTTP2/Push, era muy difícil evitar enviar subrecursos que el navegador ya tenía. Este efecto de "sobrecarga" generaba un uso menos eficiente del ancho de banda de la red, lo que dificultaba significativamente los beneficios de rendimiento. En general, los datos de Chrome mostraron que HTTP2/Push era, de hecho, un factor negativo neto para el rendimiento en la Web.

Por el contrario, los indicadores anticipados tienen un mejor rendimiento en la práctica porque combinan la capacidad de enviar una respuesta preliminar con sugerencias que dejan al navegador a cargo de recuperar o conectarse a lo que realmente necesita. Si bien los indicadores anticipados no abarcan todos los casos de uso que HTTP2/Push podría abordar en teoría, creemos que los indicadores anticipados son una solución más práctica para acelerar las navegaciones.

Imagen en miniatura de Pierre Bamin.