Entrevista Frontend: ¿Cuándo mejora realmente el LCP con HTTP 103 Early Hints?

Planteamiento y contexto

Eres responsable de la página de inicio de un comercio electrónico cuyo HTML above-the-fold tarda tiempo en generarse. La propuesta es enviar 103 Early Hints antes de la respuesta final para que el navegador pueda iniciar la carga de CSS, fuentes o scripts críticos. Explica cuándo resulta útil, cómo evitar descargas duplicadas y cómo verificar el cambio en el LCP. Asume una navegación de nivel superior sobre HTTP/2 o HTTP/3, manteniendo el envío de los encabezados Link correctos en la respuesta final.

Qué evalúa el entrevistador

• Si describes 103 como una sugerencia y no como una lista autoritativa de recursos: el navegador puede conectarse o precargar, mientras que la respuesta final sigue siendo la autoritativa.
• Si identificas el tiempo de procesamiento del servidor (think-time) como la ventana de solapamiento; cuando el servidor puede responder 200 inmediatamente, un preload o preconnect estándar en la respuesta principal es más simple.
• Si cubres la estabilidad de los recursos, el almacenamiento en caché, las redirecciones entre orígenes (cross-origin), la compatibilidad de los navegadores y los requisitos de protocolo.
• Si validas con LCP, reutilización de caché, solicitudes duplicadas y errores en lugar de limitarte a recitar un código de estado.

Preguntas clarificadoras antes de responder

1. ¿Cuánto tiempo tarda el servidor antes del primer byte? Si es cercano a cero, hay poco solapamiento que ganar; optimiza primero el backend o las sugerencias de la respuesta principal.
2. ¿Son estables y necesarios los recursos sugeridos? Los recursos que dependen del usuario, de experimentos o de permisos pueden desperdiciarse si se predicen de forma anticipada.
3. ¿Es esta una navegación de nivel superior sobre HTTP/2+? El manejo de los navegadores se centra en la navegación, y MDN recomienda HTTP/2 o posterior.
4. ¿Son recursos almacenables en caché? Una precarga no almacenable en caché puede descargarse nuevamente después de que llegue el HTML, convirtiendo la sugerencia en trabajo adicional.

Marco de respuesta de 30 segundos

“Primero verifico que la página tenga un tiempo de procesamiento del servidor significativo y que sea una navegación donde el cliente soporte 103. Luego, sugiero únicamente CSS, fuentes u orígenes de conexión que sean estables y almacenables en caché, repitiendo los encabezados Link correctos en la respuesta final. Evito sugerencias para recursos que dependan de experimentos o permisos. Antes y después del lanzamiento, comparo el solapamiento entre TTFB y las solicitudes de recursos, el LCP, los bytes duplicados y los errores; los clientes que no soportan 103 utilizan la ruta de respuesta normal.”

Respuesta detallada paso a paso

1. Cuantificar la ventana de solapamiento

103 permite que el navegador se conecte o descargue mientras el servidor prepara el HTML final. El límite superior útil es aproximadamente el tiempo de preparación del servidor menos el momento en el que el navegador descubriría de otro modo el recurso tras la respuesta final. Si el servidor responde 200 con rapidez, la ventana es casi nula; en ese caso, Chrome recomienda usar Link estándar u link en el HTML.

2. Seleccionar recursos estables en lugar de copiar cada sugerencia del HTML

Early Hints llega antes de que se conozca el HTML final y su variante específica de usuario. Los buenos candidatos incluyen CSS compartido, scripts comunes, fuentes y conexiones críticas a CDN. Las imágenes personalizadas, las ramas de experimentos y los recursos sujetos a permisos deben esperar al HTML. Cuando sea práctico, divide un recurso en una parte estable para la sugerencia y una parte dinámica para la respuesta final.

3. Tratar la caché y el protocolo como condiciones de corrección

La página final debe reutilizar el recurso precargado. Si no es almacenable en caché, el navegador podría descargarlo una vez con la sugerencia y otra vez tras analizar el HTML. Las fuentes de orígenes cruzados también necesitan una semántica crossorigin coincidente. MDN recomienda enviar 103 sobre HTTP/2 o posterior porque los clientes e intermediarios más antiguos pueden manejar incorrectamente las respuestas 1xx.

4. Mantener la respuesta final como autoritativa

Continúa enviando los encabezados Link en la respuesta final para los clientes que ignoran 103 y para los recursos descubiertos durante el renderizado del HTML. Una redirección de origen cruzado puede provocar que los navegadores descarten las conexiones y recursos anticipados, por lo que 103 no es una orden de descarga irrevocable.

5. Medir con un experimento real

Aleatoriza navegaciones reales con y sin Early Hints. Registra el tiempo de procesamiento del servidor, los tiempos de inicio de las solicitudes de recursos, el LCP, los bytes duplicados y la tasa de errores. Chrome DevTools expone el iniciador de Early Hints y la reutilización de la caché, pero la caché debe permanecer habilitada durante la prueba. Si el LCP no mejora, verifica si el recurso ya estaba en caché, si la sugerencia llegó demasiado tarde, si una redirección la descartó o si el tiempo del servidor no es el cuello de botella.

6. Contrastar con HTTP/2 Push

103 proporciona una pista y deja al navegador el control de la descarga; HTTP/2 Push enviaba recursos activamente y a menudo duplicaba elementos que ya estaban en la caché del navegador. La contrapartida es que Early Hints todavía requiere un viaje de ida y vuelta (round trip) y depende de la compatibilidad del navegador, pero evita quitarle el control al cliente.

Respuesta de ejemplo de alta calidad

Comenzaría con el tiempo antes del primer byte. Si el SSR tarda 300 milisegundos y el CSS principal y la fuente son estables en cada navegación, 103 puede solapar su conexión y descarga con esos 300 milisegundos. Sugeriría únicamente recursos estables y almacenables en caché, incluiría el crossorigin adecuado para fuentes de orígenes cruzados y dejaría las imágenes personalizadas y los scripts de experimentos para la respuesta final. La respuesta final seguiría incluyendo Link para que los clientes sin compatibilidad tengan una alternativa normal.

No afirmaría que agregar un código de estado garantice una mejora. Ejecutaría un experimento de navegación controlado y compararía el LCP, los tiempos de inicio de solicitudes, los bytes duplicados y la tasa de redirecciones entre orígenes. Si el servidor ya responde 200 rápidamente, el recurso está en caché o la página final rechaza la sugerencia con frecuencia, una sugerencia estándar en la respuesta principal —o ninguna precarga— es más segura. Esa respuesta expone la ventana de beneficio, el costo de las predicciones erróneas y el mecanismo de respaldo.

Errores comunes

• Error → Tratar 103 como equivalente a 200. Por qué falla: 103 es informativo; la respuesta final define el resultado y los recursos. Corrección: explicar que la sugerencia puede ignorarse y conservar los encabezados Link finales.
• Error → Copiar cada preload del HTML en 103. Por qué falla: las variantes de usuario se desconocen al momento de la sugerencia, por lo que los recursos dinámicos desperdician ancho de banda. Corrección: elegir únicamente recursos estables y de alta probabilidad.
• Error → Medir solo el LCP. Por qué falla: una precarga no almacenable en caché o un atributo cross-origin incorrecto pueden iniciar antes mientras aumentan los bytes totales. Corrección: medir también la reutilización de caché, solicitudes duplicadas, ancho de banda y errores.
• Error → Enviarlo en cada solicitud HTTP/1.1. Por qué falla: el manejo de 1xx varía y Early Hints está orientado a la navegación. Corrección: condicionar según protocolo, tipo de solicitud y capacidad del cliente, con respaldo a la respuesta normal.

Preguntas de seguimiento y respuestas

La respuesta final a menudo redirige a otro origen. ¿Enviarías aún 103?

Solo con precaución. Las directrices de MDN y Chrome señalan que una redirección de origen cruzado puede hacer que los navegadores descarten las conexiones y recursos anticipados. Restringe las sugerencias a un punto de entrada final estable o a recursos del mismo origen que sobrevivan a la redirección, y establece un umbral de tasa de redirección.

El CSS difiere entre grupos de experimento. ¿Qué puedes sugerir?

Sugiere únicamente el CSS compartido por todos los grupos; deja los fragmentos específicos del experimento para el HTML final. Si no existe una intersección estable, no precargues. El costo de ancho de banda de una predicción errónea puede superar el tiempo de espera ahorrado.

¿Cómo demuestras que la mejora provino de 103 y no de una caché caliente?

Aleatoriza grupos con estados de caché equivalentes y reporta las cachés frías y calientes por separado. Mide el solapamiento entre las solicitudes de recursos y el tiempo de procesamiento del servidor, no solo un valor aislado de LCP; inspecciona el iniciador de Early Hints, los aciertos de caché (cache hits) y las descargas duplicadas.

¿Qué sucede si un navegador no soporta una directiva específica de Early Hints?

Conserva el Link final y las declaraciones HTML como alternativa. Comienza con el ampliamente soportado preconnect, implementa preload según la matriz de navegadores objetivo y monitorea los errores.