103 Early Hints: precarga recursos críticos durante el tiempo de procesamiento del servidor

Última revisión por Arjen Karel en marzo de 2026

¿Qué son los 103 Early Hints?

Early Hints es un código de estado HTTP (103) que el servidor web envía antes de la respuesta final. Le permite indicar al navegador, en una fase temprana de la carga, que ciertos recursos como una imagen o una hoja de estilo son críticos para renderizar la página.

La mayoría de las páginas dinámicas tardan en generarse. El servidor consulta una base de datos, ejecuta la lógica de la aplicación y monta el HTML. Durante ese tiempo de procesamiento, el navegador solo espera. Los 103 Early Hints cubren ese hueco indicando al navegador qué descargar mientras espera la respuesta real.

Early Hints sustituye al obsoleto HTTP/2 Server Push, que Chrome eliminó en la versión 106. Server Push empaquetaba recursos con la respuesta final y a menudo enviaba bytes que el navegador ya tenía en caché. Early Hints evita ese problema porque solo sugiere: el navegador decide si actuar o no.

Compatibilidad con navegadores

El 93% de los navegadores a nivel mundial admite 103 Early Hints:

• Chrome 103+ y Edge 103+: compatibilidad total con preconnect y preload (desde junio de 2022)
• Firefox 123+: compatibilidad total con preconnect y preload (desde febrero de 2024)
• Safari 17+: solo preconnect. Safari no admite preload en respuestas 103

La limitación de Safari importa. Si tu estrategia de Early Hints depende por completo del preload de imágenes o fuentes, los usuarios de Safari no verán ninguna mejora. Incluye sugerencias de preconnect junto con las de preload para que Safari al menos prepare la conexión con los orígenes de tus recursos.

Early Hints solo funciona sobre HTTP/2 o HTTP/3. No funciona sobre HTTP/1.1, desde iframes ni en peticiones que no sean de navegación. El navegador solo procesa sugerencias de preload y preconnect; las respuestas 103 no admiten dns-prefetch ni prefetch.

¿Cómo son los 103 Early Hints?

Cuando el navegador solicita una página, el servidor devuelve de inmediato una respuesta 103 antes de terminar de generar el HTML. Esta respuesta le indica al navegador que empiece a descargar la imagen del LCP y la hoja de estilo:

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Mientras tanto, el servidor genera la página. En cuanto está lista, envía la respuesta final:

HTTP/2 200 OK
Content-Length: 1234
[el resto de la respuesta]

Para cuando el navegador recibe la respuesta 200, ya ha empezado a descargar la imagen y la hoja de estilo. Esa ventaja es la que acelera el Largest Contentful Paint.

Cómo enviar 103 Early Hints

Tienes tres opciones principales, de la más sencilla a la que ofrece mayor control.

Cloudflare (la más sencilla)

Si ya usas Cloudflare para optimizar el rendimiento, activar Early Hints requiere un solo clic. Ve a Speed > Settings > Content Optimization y activa Early Hints. Está disponible en todos los planes, incluido el gratuito.

Cloudflare almacena en caché las cabeceras Link de las respuestas 200 del servidor de origen. En las peticiones posteriores, envía esas cabeceras cacheadas como una respuesta 103 antes de reenviar la petición al origen. Tú defines las sugerencias enviando cabeceras Link desde la aplicación:

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (nativo desde 1.29.0)

NGINX añadió compatibilidad nativa con 103 Early Hints en la versión 1.29.0 (junio de 2025). La directiva early_hints reenvía las respuestas 103 del backend al cliente:

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

El mapeo de sec-fetch-mode garantiza que las sugerencias solo se envíen en peticiones de navegación sobre HTTP/2 o HTTP/3. La aplicación del backend debe generar la respuesta 103; NGINX se limita a transmitirla.

Apache (2.4.58+)

Apache puede generar respuestas 103 por sí mismo mediante mod_http2. Actívalo con la directiva H2EarlyHints y define los recursos que quieras sugerir:

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

A diferencia de NGINX, Apache genera la respuesta 103 a nivel de servidor, sin que tu aplicación tenga que producirla.

Cuándo ayudan los Early Hints (y cuándo no)

Los 103 Early Hints son más eficaces cuando el servidor tarda un tiempo considerable en responder: páginas dinámicas que consultan bases de datos, llaman a APIs o renderizan plantillas. Cuanto más lento sea el Time to First Byte, más tiempo tendrá el navegador para aprovechar las sugerencias.

Early Hints aporta menos ventajas cuando:

• El servidor responde en menos de 100 ms. Si el TTFB ya es rápido, no hay tiempo muerto que el navegador pueda aprovechar. Céntrate en su lugar en la priorización de recursos dentro del HTML.
• Las páginas se sirven desde la caché. Una respuesta HTML completamente en caché carga tan rápido que la respuesta 103 apenas tiene margen de ventaja.
• Sugieres demasiados recursos. Sugerir más de 10 recursos satura la conexión y puede ralentizar la carga. Shopify comprobó que, en dispositivos móviles, un uso agresivo de Early Hints empeoraba el TTFB, el FCP y el LCP. Limítate a entre 2 y 4 recursos críticos.

A pesar de contar con un 93% de compatibilidad en navegadores, su adopción sigue siendo baja. Según el Web Almanac de 2025, solo alrededor del 5% de los sitios web principales utiliza 103 Early Hints. El principal obstáculo es saber qué recursos sugerir en cada página, algo que la mayoría de los CMS no gestiona de forma automática.

Cómo verificar que Early Hints funciona

Abre Chrome DevTools, ve al panel Network y recarga la página. Haz clic en la petición del documento y revisa las cabeceras de respuesta. Si Early Hints está funcionando, verás un estado 103 antes del 200 en el desglose de tiempos.

Desde la línea de comandos, puedes comprobarlo con curl:

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Deberías ver tanto una respuesta 103 como una 200.

Resultados de las pruebas

Probé dos escenarios para medir el impacto en el First Contentful Paint y el Largest Contentful Paint.

1. Early Hints solo en la imagen del LCP

La imagen del LCP apareció en pantalla un 35% antes con 103 Early Hints en comparación con un preload habitual en el HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints con una hoja de estilo pesada y la imagen del LCP

Añadir un archivo CSS de 85 kb a las sugerencias hizo la diferencia todavía más evidente. El FCP mejoró de 1,8 segundos a 1,4 segundos, y el LCP mejoró de 3,2 segundos a 2,0 segundos.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Estas cifras encajan con lo que Cloudflare midió en más de 100.000 clientes: una mejora del LCP del 6% en el percentil 50 y del 16% en el percentil 75 en escritorio. Shopify observó una mejora del LCP de 500 ms en p50 durante el Black Friday y el Cyber Monday. Las mayores ganancias se obtienen en páginas con tiempos de respuesta del servidor lentos, que es justo cuando Early Hints dispone de más tiempo para actuar.

Early Hints y el TTFB

Hay un matiz de medición que debes tener en cuenta. Desde Chrome 133, la métrica responseStart del navegador (utilizada por la mayoría de las herramientas para reportar el TTFB) incluye la respuesta 103. Esto significa que el TTFB reportado bajará tras activar Early Hints, aunque el tiempo real de procesamiento del servidor no haya cambiado.

Si necesitas medir el tiempo de procesamiento del servidor por separado, Chrome 133 introdujo la nueva marca de tiempo firstResponseHeadersStart, que registra cuándo llegan las cabeceras de la respuesta 200 definitiva. Las herramientas de Real User Monitoring que registran ambos valores te dan la foto completa: cuánto tiempo ahorró Early Hints al navegador y cuánto tardó realmente el servidor en responder.