Optimiza el LCP Resource Load Delay

Esta guía es parte de la sección de Largest Contentful Paint (LCP) de nuestro centro de recursos de Core Web Vitals. El Resource Load Delay es una de las cuatro fases secuenciales del LCP y es frecuentemente el mayor contribuyente individual a una puntuación de LCP deficiente. Este artículo cubre las causas, los diagnósticos y las soluciones en profundidad.

Optimiza el LCP Resource Load Delay

Largest Contentful Paint (LCP) se compone de cuatro fases: TTFB, Resource Load Delay, Resource Load Duration y Element Render Delay. Los esfuerzos de desarrollo suelen centrarse en reducir la Load Duration mediante compresión de archivos, pero esto pasa por alto el Resource Load Delay, que es frecuentemente una fuente mayor de latencia. Este retraso antes de que comience la descarga puede añadir cientos de milisegundos a tu LCP, provocando que supere el umbral de 2,5 segundos considerado como 'Bueno'.

Un consejo rápido: si tu LCP es una imagen, casi siempre va a ser peor que si fuera texto. Debes rastrear los tipos de elementos LCP en tus datos de RUM, de lo contrario estarás navegando a ciegas.

Definición precisa: la espera crítica antes de la descarga

El Resource Load Delay es el tiempo entre el TTFB y el momento en que el navegador inicia la descarga del recurso LCP. No es el tiempo de descarga; es la latencia de descubrimiento que ocurre antes de que comience la solicitud. Un valor alto aquí indica un problema arquitectónico en el que el navegador no puede encontrar la URL del recurso en el payload HTML inicial. Este resource load delay puede verse como el tiempo que el navegador dedica a identificar que el recurso LCP es necesario y a decidir descargarlo.

Para los elementos LCP basados en texto y renderizados con una fuente del sistema, este resource load delay es típicamente cero porque no se necesita descargar ningún recurso externo. Los valores más altos de resource load delay son específicos de elementos LCP que dependen de un recurso de red externo, como una imagen o un archivo de video.

El motor del descubrimiento: Preload Scanner vs. DOM Parser

Para reducir el Resource Load Delay, debes entender cómo los navegadores descubren los recursos. La eficiencia de este proceso de descubrimiento es el factor principal que determina la latencia. Los navegadores utilizan dos mecanismos: una vía rápida y una vía lenta.

• El Preload Scanner (la vía rápida): Es un parser secundario de alta velocidad que escanea el HTML en bruto en busca de URLs de recursos, como las que aparecen en etiquetas <img> o <link>. Las pone en cola para su descarga inmediatamente, antes de que se analice el CSS o se ejecute JavaScript. Esta es la vía óptima para cualquier recurso crítico.
• El DOM Parser (la vía lenta): Es el parser principal que construye el Document Object Model (DOM) completo y el CSS Object Model (CSSOM). Los recursos no encontrados en el HTML inicial, como una CSS background-image o un elemento inyectado por JavaScript, solo son descubiertos por este parser. Esta es la vía lenta porque depende de que otros archivos se descarguen y ejecuten primero, creando una cadena de dependencias que introduce alta latencia.

Toda la estrategia para optimizar el Resource Load Delay se basa en un principio: asegurar que la URL del recurso LCP sea descubrible por el preload scanner. Cualquier patrón que oculte la URL del documento HTML inicial obliga al navegador a usar la vía lenta de descubrimiento. Este período de espera se traduce directamente en Resource Load Delay. Cada optimización efectiva consiste en diseñar tu HTML para colocar el recurso LCP en la vía rápida. Para una guía completa sobre la priorización de recursos del navegador, consulta nuestro artículo sobre priorización de recursos.

Por qué importa el Load Delay

Un error común es pensar que un LCP lento es un problema de "tamaño de archivo". Esto lleva a los equipos a centrarse únicamente en la compresión de imágenes para reducir la Resource Load Duration. Si bien la optimización de activos es un factor, el análisis de datos de campo reales muestra que, para muchos sitios con un LCP deficiente, el Resource Load Delay es el principal cuello de botella de rendimiento, no la Resource Load Duration.

Los datos de campo muestran que el sitio mediano con una puntuación de LCP deficiente tiene un Resource Load Delay de 1,3 segundos. Eso es más de la mitad del presupuesto total de 2,5 segundos para una puntuación de LCP 'Buena', todo consumido antes de que la descarga del recurso LCP siquiera comience. Los datos indican que estos sitios pasan casi cuatro veces más tiempo esperando a que comience la descarga que en la descarga misma.

Estos datos exponen una frecuente mala orientación del esfuerzo de desarrollo. Los equipos pueden pasar semanas eliminando kilobytes de las imágenes para acortar la Load Duration en unos pocos milisegundos, mientras un problema arquitectónico que causa un Load Delay de 1,5 segundos permanece sin resolver. El LCP es un proceso secuencial; un retraso en una fase temprana no puede recuperarse optimizando una fase posterior. Si una solicitud se retrasa más de un segundo, una diferencia de 100ms en el tiempo de descarga es irrelevante para la puntuación final de LCP. Las optimizaciones de mayor impacto implican cambios arquitectónicos, como mejorar la descubribilidad de los recursos, no solo la compresión de activos. El enfoque debe pasar de hacer los activos más pequeños a asegurar que se descubran antes.

Cómo detectar el Resource Load Delay

Para corregir el Resource Load Delay, primero debes medirlo con precisión. El flujo de trabajo profesional consiste en definir primero el problema con datos de usuarios reales (RUM) y solo después pasar a Chrome DevTools para un análisis profundo.

Paso 1: Analizar datos de campo (RUM)

Los datos de campo, o Real User Monitoring (RUM), se recopilan de sesiones de usuarios reales. Las herramientas de RUM, como el Chrome User Experience Report (CrUX) público o mi propia herramienta, CoreDash, responden a la pregunta: ¿qué está pasando en el mundo real? Una herramienta de RUM completa también proporcionará un desglose de las sub-partes del LCP, mostrándote la mediana del Resource Load Delay entre tus usuarios. Estos datos validan que existe un problema de LCP, muestran qué URLs están afectadas y revelan los elementos LCP comunes que tus usuarios realmente están viendo. Debes comenzar aquí para confirmar que estás resolviendo un problema real.

Paso 2: Diagnosticar con DevTools

Una vez que tus datos de RUM han identificado una página objetivo y un elemento LCP, usas Chrome DevTools para diagnosticar la causa. El objetivo aquí es reproducir el problema y medir las sub-partes del LCP para obtener un valor preciso del Resource Load Delay. DevTools también es donde realizas un análisis del hilo principal (Main Thread Analysis) para ver exactamente qué tareas se están ejecutando y potencialmente bloqueando el proceso de renderizado.

Guía paso a paso del panel de rendimiento de Chrome DevTools

El panel de rendimiento (Performance) en Chrome DevTools es una herramienta indispensable para analizar el LCP y cuantificar el load delay.

1. Configuración:

• Abre Chrome DevTools haciendo clic derecho en la página y seleccionando "Inspeccionar" o usando el atajo Ctrl+Shift+I (Windows/Linux) o Cmd+Option+I (Mac).
• Navega a la pestaña Performance.
• Asegúrate de que la casilla Web Vitals esté habilitada en la configuración de captura. Esto superpondrá la información de Core Web Vitals en la línea de tiempo de rendimiento.
• Para simular condiciones realistas de usuario, aplica limitación de CPU y red. Una "ralentización 4x" para CPU y un perfil de red "Fast 3G" o "Slow 4G" son puntos de partida comunes para pruebas en móviles.

2. Grabación de un perfil de rendimiento:

• Haz clic en el botón "Record and reload page" (un icono de flecha circular) en el panel de rendimiento. Esto iniciará una grabación, recargará la página y luego detendrá la grabación una vez que la página esté completamente cargada.

3. Análisis e interpretación:

• Pista de Timings: En la vista principal de la línea de tiempo, localiza la pista Timings. Verás un marcador con la etiqueta LCP. Al pasar el cursor sobre este marcador, se resaltará el elemento LCP correspondiente en la captura de pantalla del viewport principal y se mostrará el tiempo total de LCP.
• Desglose de LCP por fases: Haz clic en el marcador LCP en la pista Timings. En la pestaña Summary en la parte inferior del panel, encontrarás un desglose detallado del tiempo de LCP. Este desglose muestra explícitamente la duración de cada una de las cuatro sub-partes, incluyendo el Load delay, medido en milisegundos. Este valor es la medición más directa y precisa del Resource Load Delay para esa carga de página específica.
• Análisis del hilo principal: Mientras examinas la línea de tiempo, observa la pista Main en busca de tareas largas (bloques de actividad marcados con un triángulo rojo). Si estas tareas largas ocurren después de que el recurso LCP ha terminado de cargarse pero antes del marcador LCP, probablemente están contribuyendo al Element Render Delay, un problema relacionado pero distinto.

Causas comunes y soluciones de alto impacto

Un Resource Load Delay alto es causado por una de dos cosas: el recurso LCP se descubre tarde o se le asigna una prioridad de descarga baja. Aquí están los errores arquitectónicos más comunes y sus soluciones.

Causa: LCP cargado mediante CSS

El problema: El preload scanner no analiza archivos CSS. Cuando tu imagen LCP se define con una CSS background-image, su URL es invisible para este escáner de alta velocidad. El navegador solo puede descubrir la imagen después de descargar el HTML, encontrar el enlace al archivo CSS, descargar el archivo CSS, construir el CSSOM y luego aplicar el estilo. Esta cadena de dependencias causa directamente un alto Resource Load Delay. Para más información sobre este patrón, consulta nuestra guía sobre diferir imágenes de fondo.

La solución: La implementación correcta es evitar usar background-image para cualquier elemento LCP crítico. Usa una etiqueta <img> estándar en su lugar. Esto coloca la URL de la imagen directamente en el HTML donde el preload scanner puede encontrarla de inmediato. Puedes lograr el mismo resultado visual con CSS.

Ejemplo de implementación:

Anti-patrón (no hagas esto):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Buena práctica (haz esto en su lugar):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Un texto alternativo descriptivo para la imagen hero"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Título de la página</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalente a top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Esta propiedad imita background-size: cover */
      z-index: -1; /* Coloca la imagen detrás de otro contenido */
    }
    

Esta implementación proporciona el mismo resultado visual pero hace que la imagen LCP sea descubrible en el momento más temprano posible, lo que minimiza su load delay.

Causa: renderizado del lado del cliente e inyección mediante JavaScript

El problema: Las aplicaciones que usan frameworks de renderizado del lado del cliente (CSR) como React o Vue a menudo sirven un shell HTML mínimo. El contenido real, incluida la etiqueta <img> del LCP, solo se inserta en el DOM mediante JavaScript después de que se descargan, analizan y ejecutan grandes bundles del framework. Este proceso oculta fundamentalmente el recurso LCP del preload scanner, creando una alta latencia de descubrimiento.

La solución: La solución más efectiva es mover el renderizado inicial del cliente al servidor.

• Server-Side Rendering (SSR) o Static Site Generation (SSG): Patrones arquitectónicos como SSR o SSG generan el HTML completo en el servidor. El navegador recibe un documento completo que contiene la etiqueta <img> y su atributo src, haciendo que el recurso LCP sea inmediatamente descubrible por el preload scanner. Esta es la arquitectura requerida para cualquier página crítica en rendimiento.
• Optimizaciones específicas del framework: Los frameworks modernos también proporcionan optimizaciones integradas. Por ejemplo, el componente <Image> de Next.js tiene una propiedad priority. Establecerla en true indica al framework que añada automáticamente los atributos correctos de <link rel="preload"> y fetchpriority="high", asegurando que la imagen se descubra y se descargue con la prioridad correcta.

Causa: usar loading="lazy" en la imagen LCP

El problema: Este es un error frecuente y de alto impacto. El atributo loading="lazy" es una instrucción directa al navegador para retrasar la descarga de una imagen hasta que esté cerca del viewport. Si bien esta es la optimización correcta para imágenes fuera de la pantalla (below-the-fold), aplicarla a un elemento LCP visible (above-the-fold) es contraproducente. El preload scanner del navegador está diseñado para ignorar las imágenes con loading="lazy", lo que garantiza un descubrimiento tardío y un alto Resource Load Delay.

La solución: La solución requiere diligencia.

• Elimina loading="lazy" de la imagen LCP: Cualquier imagen que probablemente sea el elemento LCP no debe tener el atributo loading="lazy". El comportamiento predeterminado del navegador es loading="eager", que es la configuración correcta para contenido crítico visible en la parte superior de la página. Omitir el atributo loading por completo tiene el mismo efecto.
• Audita y configura herramientas de terceros: También debes auditar las herramientas de terceros. Muchas plataformas CMS como WordPress y varios plugins de optimización de imágenes aplican automáticamente la carga diferida a todas las imágenes. Es esencial configurar estas herramientas para excluir la imagen LCP de este comportamiento. Esto a menudo implica crear una regla de exclusión para las primeras una o dos imágenes de la página.

Causa: estructura HTML subóptima y documentos grandes

El problema: El preload scanner procesa el documento HTML de arriba a abajo. Si recursos no críticos pero que consumen mucho ancho de banda, como iconos del encabezado o scripts de widgets de chat, están colocados más arriba en el <body> que el elemento LCP, se descubren y se ponen en cola para descarga primero. Esto consume el ancho de banda inicial de la red y puede retrasar la descarga del recurso LCP. Un documento HTML grande también puede ser un problema; si el elemento LCP no está en el primer fragmento de datos que recibe el navegador (alrededor de 14KB), su descubrimiento se retrasa al menos un viaje de ida y vuelta en la red.

La solución: Optimiza la estructura y la prioridad del contenido dentro del HTML.

• Reordena el HTML: Cuando sea posible, asegúrate de que la etiqueta <img> o el bloque de texto del elemento LCP aparezca lo más temprano que puedas colocarlo dentro de la etiqueta <body>.
• Reduce la prioridad de imágenes no críticas: Para imágenes no esenciales que deben aparecer temprano en el código fuente del HTML (como iconos en el encabezado), aplica loading="lazy". Esto le dice al preload scanner que las omita, preservando la cola de descargas para el elemento LCP.
• Difiere scripts no esenciales: Los scripts para analíticas, anuncios o widgets de redes sociales rara vez son críticos para el renderizado inicial. Mueve sus etiquetas <script> al final del <body> o usa el atributo defer. Esto evita que bloqueen el parser o compitan por ancho de banda de red con el recurso LCP.

Priorización avanzada con Resource Hints

Una vez que el recurso LCP es descubrible en el HTML, puedes usar resource hints para dar al navegador instrucciones más explícitas sobre cómo descargarlo. Estos hints proporcionan un control detallado sobre el descubrimiento y la priorización.

Forzar el descubrimiento temprano con <link rel="preload">

<link rel="preload"> no es un hint; es una directiva. Obliga al navegador a descargar un recurso con alta prioridad, incluso si aún no es descubrible por el parser principal. Colocarlo en el <head> de tu HTML es la forma más directa de solucionar problemas de descubrimiento tardío para recursos como fuentes, imágenes CSS background o imágenes LCP ubicadas profundamente en el DOM. Para detalles completos de implementación y ejemplos, consulta nuestra guía dedicada sobre cómo precargar la imagen LCP.

Mecanismo

Cuando un enlace preload se coloca en el <head> del documento HTML, el preload scanner lo identifica e inmediatamente pone en cola el recurso especificado para su descarga. Esto es ideal para recursos como fuentes cargadas mediante @font-face en una hoja de estilos externa, LCP con CSS background-image (aunque usar una etiqueta <img> es preferible), o una imagen LCP que está ubicada profundamente dentro de una estructura DOM compleja.[3]

Preloading responsive

Un detalle crítico de implementación es necesario cuando se precargan imágenes responsive. Para asegurar que el navegador precargue la imagen del tamaño correcto para el viewport del usuario y evite una doble descarga innecesaria, la etiqueta <link rel="preload"> debe incluir los atributos imagesrcset e imagesizes que reflejen perfectamente los atributos de la etiqueta <img> correspondiente.[4]

Ejemplo de preloading responsive:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="Un texto alternativo descriptivo"
     fetchpriority="high"
     width="1200" height="675">
    

Posible inconveniente

El preloading resuelve el momento de la descarga (Load Delay y Load Duration) pero no el *momento del pintado*. Si el hilo principal está bloqueado por JavaScript pesado o CSS que bloquea el renderizado cuando la imagen precargada llega, la imagen aún tendrá que esperar para ser renderizada, lo que puede desplazar el cuello de botella del Load Delay al Element Render Delay.[5, 6]

Análisis profundo: fetchpriority="high" y la cola de prioridad del navegador

El atributo fetchpriority es un hint que señala la importancia relativa de la descarga de un recurso. Te permite influir en la prioridad de un recurso dentro de la cola de descargas del navegador.[7]

Cómo funciona la prioridad del navegador

Cuando el navegador descubre recursos durante la carga de la página, asigna a cada uno un nivel de prioridad interno. Por defecto, las imágenes en el viewport comienzan con prioridad "Baja" y posteriormente se actualizan a "Alta" una vez que el navegador completa el diseño y determina que son visibles. Esta actualización requiere que el navegador descargue y analice el CSS primero, lo que crea un retraso. El atributo fetchpriority="high" evita este proceso por completo al establecer la imagen en prioridad "Alta" desde el momento en que es descubierta. Esto es especialmente impactante para las imágenes LCP porque elimina el retraso de la actualización de prioridad.

preload vs. fetchpriority

Estos dos hints sirven para propósitos diferentes pero complementarios. preload afecta cuándo un recurso es descubierto y añadido a la cola. fetchpriority afecta su nivel de prioridad una vez que está en la cola. Entender esta distinción es crítico: preload resuelve el descubrimiento tardío, mientras que fetchpriority resuelve la baja priorización. Para muchas imágenes LCP que ya están en el HTML, fetchpriority por sí solo puede ser suficiente. Para una guía completa sobre cómo interactúan estos, consulta nuestro artículo sobre priorización de recursos.

Buena práctica para LCP

Para la imagen LCP, la estrategia óptima es usarlos juntos. Primero, asegura el descubrimiento temprano ya sea colocando la etiqueta <img> temprano en el HTML o usando preload. Segundo, añade fetchpriority="high" directamente a la etiqueta <img> (y al enlace preload, si se usa). Esta combinación asegura que el recurso no solo se descubra temprano, sino que también reciba la prioridad más alta posible para ganar la competencia por el ancho de banda de la red frente a otros recursos como hojas de estilo o fuentes.[3, 1, 7]

Ejemplo:

<img src="lcp-image.jpg" fetchpriority="high" alt="Una imagen hero crítica">

Cuándo usar fetchpriority="low"

El atributo fetchpriority no es solo para aumentar la prioridad. También puedes usar fetchpriority="low" para reducir la prioridad de recursos no críticos que compiten por ancho de banda con la imagen LCP. Los candidatos comunes incluyen imágenes visibles en la parte superior de la página que no son el elemento LCP (como iconos pequeños o avatares en el encabezado), y recursos precargados que son necesarios pero no urgentes. Al reducir explícitamente la prioridad de estos recursos competidores, creas más margen de ancho de banda para la imagen LCP.

<!-- Imagen LCP: alta prioridad -->
<img src="hero.jpg" fetchpriority="high" alt="Imagen hero" width="1200" height="600">

<!-- Imagen no crítica above-the-fold: baja prioridad -->
<img src="avatar.jpg" fetchpriority="low" alt="Avatar del autor" width="48" height="48">

Impacto demostrado

En un caso de estudio con Google Flights, añadir fetchpriority="high" a la imagen de fondo LCP fue instrumental para mejorar el tiempo de LCP de 2,6 segundos a 1,9 segundos, una mejora de 700ms.[8]

Optimización de conexiones de terceros: preconnect y dns-prefetch

El problema

Si tu recurso LCP está alojado en un dominio de terceros, como un CDN de imágenes o un proveedor de fuentes como Google Fonts, el navegador debe establecer una nueva conexión de red con ese dominio. Este proceso implica una búsqueda DNS, un handshake TCP y una negociación TLS, todo lo cual debe completarse antes de que se pueda descargar el primer byte del recurso. Este tiempo de configuración de la conexión es un contribuyente directo al Resource Load Delay para activos de origen cruzado (cross-origin).[9, 2, 10, 11]

Las soluciones

• preconnect: Este hint indica al navegador que realice la configuración completa de la conexión (DNS, TCP y TLS) para un origen de terceros especificado en segundo plano, con anticipación. Cuando el recurso se solicita realmente, la conexión ya está establecida, eliminando la latencia de configuración. Esto es altamente efectivo y se recomienda para los uno o dos dominios de terceros más críticos que sirven recursos LCP.[2]
• dns-prefetch: Este es un hint más ligero que solo realiza la búsqueda DNS para un dominio. Ahorra menos tiempo que preconnect pero tiene un soporte de navegadores más amplio y es útil como fallback o para dominios de terceros menos críticos.[2, 12]

Buena práctica de implementación

Para garantizar la máxima compatibilidad, proporciona ambos hints. El navegador usará preconnect si es compatible y recurrirá a dns-prefetch si no lo es. El atributo crossorigin es esencial para recursos descargados usando CORS, como las fuentes.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabla: comparación de Resource Hints para la optimización del LCP

Para prevenir el uso incorrecto y clarificar los roles distintos de estos poderosos hints, la siguiente tabla proporciona un resumen comparativo.

Estrategias holísticas y orientadas al futuro

Más allá de los hints específicos, las decisiones arquitectónicas más amplias y las funcionalidades emergentes de la plataforma web pueden proporcionar soluciones holísticas y potentes al Resource Load Delay.

El papel de un CDN moderno

Una Red de Distribución de Contenidos (CDN) es una tecnología fundamental para el rendimiento web que reduce indirecta pero significativamente el Resource Load Delay, especialmente para los recursos LCP.

• Reducción de la sobrecarga de conexión: Al distribuir activos a través de una red global de servidores, un CDN coloca el contenido geográficamente más cerca del usuario. Esto reduce inherentemente el tiempo de ida y vuelta (RTT) requerido para la búsqueda DNS, el handshake TCP y la negociación TLS, que son todos componentes del tiempo de configuración de la conexión.[13, 14, 15] Para una imagen LCP alojada en un CDN, esto reduce directamente su load delay.
• CDN de imágenes: Los CDN de imágenes especializados ofrecen un doble beneficio. Proporcionan la ventaja de proximidad de un CDN estándar mientras también automatizan muchas optimizaciones complejas que reducen la Resource Load Duration, como el redimensionamiento de imágenes al vuelo, la compresión y la conversión a formatos modernos como AVIF y WebP.[9, 1]
• Protocolos avanzados: Muchos CDN modernos aprovechan protocolos de red superiores como HTTP/3, que usa QUIC en lugar de TCP. HTTP/3 reduce el tiempo de configuración de la conexión y mitiga el bloqueo de cabeza de línea (head-of-line blocking), lo que lleva a una entrega de recursos más rápida y eficiente en general.[16]

Eliminar el retraso por completo con Speculation Rules

La Speculation Rules API es una funcionalidad de vanguardia de la plataforma web que ofrece el potencial de eliminar el retraso del LCP por completo para las navegaciones posteriores.

Mecanismo

Esta API permite a los desarrolladores informar declarativamente al navegador sobre qué URLs es probable que el usuario navegue a continuación. Basándose en estas reglas, el navegador puede optar por prerenderizar una página de destino en una pestaña oculta en segundo plano antes de que el usuario siquiera haga clic en el enlace.[3, 1, 16]

Impacto en el LCP

Cuando el usuario hace clic en un enlace a una página prerenderizada, la navegación es virtualmente instantánea. La página ya se ha cargado y renderizado completamente en segundo plano. Para esta navegación, el TTFB, Resource Load Delay, Resource Load Duration y Element Render Delay se reducen efectivamente a casi cero desde la perspectiva del usuario.[3, 1, 16]

Ejemplo de caso de uso

En una página de categoría de comercio electrónico, las speculation rules podrían usarse para prerenderizar las páginas de detalle de producto de los primeros artículos de la lista. Cuando un usuario hace clic en uno de estos productos, la página aparece instantáneamente, proporcionando una experiencia fluida y excepcionalmente rápida.

Síntesis de casos de estudio: de la teoría a la práctica

La efectividad de estas estrategias de optimización no es meramente teórica; está demostrada por datos de pruebas y escenarios del mundo real.

• Caso 1: el poder transformador del preloading: Un experimento realizado por DebugBear en una página con un alto load delay proporciona un ejemplo dramático. La imagen LCP estaba oculta en una cadena de solicitudes, lo que causaba que el Resource Load Delay representara un asombroso 75% del tiempo total de LCP. Al implementar un único hint <link rel="preload"> para hacer la imagen descubrible tempranamente, el Resource Load Delay se redujo a solo el 2% del tiempo de LCP.[17] Esto demuestra cómo una simple corrección arquitectónica puede resolver un cuello de botella de rendimiento masivo.
• Caso 2: el anti-patrón de loading="lazy" en el mundo real: Un desarrollador en Stack Overflow reportó un LCP de escritorio con un desconcertante load delay de 1.430ms a pesar de una red rápida. La causa se rastreó hasta un plugin de optimización de imágenes que estaba aplicando incorrectamente la carga diferida a la imagen LCP al reemplazar su atributo src con un SVG transparente de marcador de posición. La solución definitiva fue deshabilitar este comportamiento para el elemento LCP, permitiéndole ser descubierto y cargado de forma eager.[18] Esto ilustra cómo las herramientas de terceros pueden introducir inadvertidamente retrasos de carga severos.
• Caso 3: el impulso de rendimiento de fetchpriority: El caso de estudio de Google Flights proporciona evidencia clara del impacto de la priorización explícita. Con solo añadir fetchpriority="high" a la imagen de fondo LCP de la página, la puntuación de LCP mejoró en 700ms, bajando de 2,6 segundos a 1,9 segundos.[8] Esto demuestra que incluso cuando un recurso es descubrible, señalar su alta importancia al navegador es un paso crítico para ganar la carrera por el ancho de banda de la red.

Inspección de red en Chrome DevTools: Usa el atajo Ctrl + Shift + I para abrir las herramientas de desarrollo de Chrome, luego selecciona la pestaña "Network" y recarga la página. Observa la secuencia de carga. Tu recurso LCP debería ser uno de los primeros elementos en cola para descarga. Si está rezagado detrás de otros elementos, hay un problema de resource load delay. A continuación se muestra un ejemplo de un sitio donde el resource load delay no ha sido optimizado.

Aprovecha los datos de Real User Monitoring (RUM): Las herramientas de Real User Monitoring a menudo registran datos de atribución del LCP. Con RUM, puedes visualizar el desglose de las sub-partes del LCP (a lo largo del tiempo o por página), lo que te da una imagen clara del load delay para los elementos LCP en todo tu sitio o por página. El ejemplo a continuación muestra un desglose global del LCP junto con el load delay correspondiente.

Cómo mejorar el Load Delay

Un resource load delay ocurre cuando el orden de descarga y el momento de los recursos no son óptimos. Hay, en esencia, dos formas directas de solucionarlo: priorizar el recurso LCP o reducir la prioridad de los recursos que no son LCP. Exploremos algunos patrones comunes:

Consejo para LCP: entiende el Preload Scanner: Los navegadores modernos usan un mecanismo llamado preload scanner, que escanea rápidamente el HTML y pone los recursos en cola para su descarga. Si un recurso no puede ser puesto en cola por el preload scanner, tendrá que esperar al DOM parser, que es más lento, lo que resulta en retrasos. Asegurar que tus recursos LCP sean descubribles por el preload scanner puede marcar una gran diferencia en la reducción del load delay.

1. Optimiza la estructura del HTML

El navegador (o el preload scanner) procesa tu HTML de arriba a abajo, poniendo los recursos en cola en el orden en que aparecen. Esto significa que cuanto más arriba aparezca el recurso LCP en el HTML, antes se pondrá en cola. Para optimizar esto, elimina o difiere los recursos innecesarios de la parte superior del HTML:

• Carga diferida de imágenes ocultas o sin importancia: A veces, imágenes (por ejemplo, banderas para versiones en idiomas específicos de tu sitio o imágenes en el menú) se encuentran en la parte superior del HTML de tu sitio. Estas imágenes no son ni de lejos tan importantes como el elemento LCP. Al aplicar carga diferida a estas imágenes, el preload scanner las omite y se ponen en cola un poco más tarde durante el proceso de carga.
• Mueve los scripts sin importancia al final de la página: Mueve los scripts que son absolutamente innecesarios para la carga inicial al final de la página para evitar que retrasen los recursos críticos. Por ejemplo, un widget de chat. ¡Nadie en la historia de internet ha necesitado chatear antes de que la página fuera visible!

2. Evita las imágenes de fondo (background images)

Las imágenes de fondo son invisibles para el preload scanner, lo que significa que siempre serán puestas en cola por el DOM parser, que es mucho más lento. Para evitar este retraso, usa una etiqueta <img> regular en su lugar, combinada con la propiedad CSS object-fit: cover para imitar la apariencia de una imagen de fondo. De esta forma, el preload scanner puede detectar y poner en cola la imagen inmediatamente.

3. Usa Fetch Priority

Añade el atributo fetchpriority="high" a tu elemento LCP para indicar al navegador que debe priorizar este recurso desde el inicio. Normalmente, las imágenes se cargan con una prioridad baja o media por defecto. Durante la fase de diseño, el navegador actualiza los elementos visibles a alta prioridad. Al establecer fetchpriority="high", la descarga comienza inmediatamente con alta prioridad, asegurando un LCP más rápido.

Fetchpriority es generalmente menos intrusivo (y menos efectivo) que el preloading porque establece la prioridad relativa de un elemento (en este caso, la imagen es relativamente más importante que otras imágenes) pero no la hace más importante que, por ejemplo, las hojas de estilo o los scripts no bloqueantes.

<img src="hero-image.jpg" alt="Imagen Hero" fetchpriority="high">

4. Implementa preloading

El preloading cambia el orden en que el preload scanner pone los archivos en cola. Coloca la etiqueta <link rel="preload"> en el head de la página para indicar al navegador que descargue los recursos críticos, como la imagen LCP, lo antes posible. Los preloads pueden usarse para precargar recursos que se referencian más adelante en el HTML (y por lo tanto se ponen en cola más tarde) o incluso para precargar recursos que aún no se referencian en el HTML (como ocurre con algunos sliders). Para máxima efectividad, se recomienda colocar los preloads después de las hojas de estilo y antes de los scripts en el head de la página.

<link rel="preload" as="image" href="hero-image.jpg">

5. Optimiza los estilos

Las hojas de estilo normalmente se ponen en cola antes del recurso LCP y eso es por una buena razón. Sin hojas de estilo, el navegador no sabrá cómo se verá la página y no podrá iniciar la fase de renderizado. Sin embargo, un tamaño excesivo de CSS y un número excesivo de hojas de estilo competirán con el recurso LCP por el ancho de banda temprano.

6. Implementa carga diferida eficiente

El atributo loading puede ser un arma de doble filo. Usa loading="eager" (o simplemente omite el atributo ya que "eager" es el valor predeterminado del navegador) para tu recurso LCP, mientras aplicas loading="lazy" para las imágenes fuera de la pantalla.

• Carga eager del elemento LCP: Si el elemento LCP tiene carga diferida, no será puesto en cola por el preload scanner y se cargará mucho más tarde, impactando negativamente el rendimiento.
• Carga diferida de imágenes del viewport: Para imágenes que están en el viewport visible pero no son recursos LCP, usa loading="lazy" para ponerlas en cola para descarga un poco más tarde. Esto reduce la competencia por ancho de banda con el recurso LCP.
• Evita la carga diferida de imágenes fuera de pantalla: Las imágenes que no están en el viewport visible no activarán ninguna descarga en absoluto, eliminando completamente la competencia por ancho de banda.

7. Caché del navegador

La caché del navegador te permite omitir las solicitudes de red para recursos que ya se han almacenado localmente en el dispositivo del usuario. Aunque no acelerará la primera vista de la página, mejorará los tiempos de carga para las vistas posteriores y los visitantes recurrentes. Así es como la caché del navegador ayuda con el resource load delay:

• Almacena en caché los recursos competidores: Si bien almacenar en caché el recurso LCP en sí es una gran estrategia, la caché del navegador mejora los resource load delays del LCP al almacenar recursos de red que podrían competir con o retrasar el recurso LCP, como scripts, hojas de estilo e imágenes.
• Reduce la carga del servidor: La caché disminuye el número de solicitudes enviadas a tu servidor, lo que puede mejorar el rendimiento de otros recursos al liberar ancho de banda y reducir los ciclos de CPU del servidor.

8. Usa Speculation Rules

Speculation Rules permite a los navegadores precargar o prerenderizar páginas web basándose en la navegación predicha del usuario. La precarga (prefetching) elimina efectivamente la sub-parte de Time to First Byte del LCP y no tiene impacto en el resource load delay. El prerenderizado renderiza la siguiente página en una pestaña oculta y descarga todos los recursos de la página. Esto elimina todos los load delays para el elemento LCP como se muestra en este ejemplo de desglose de LCP de una página prerenderizada.

9. Evita el renderizado del lado del cliente

Próximos pasos: continúa optimizando el LCP

El Resource Load Delay es solo una de las cuatro fases del LCP. Una vez que hayas minimizado la latencia de descubrimiento, continúa con estas guías relacionadas:

• Identifica y corrige problemas de LCP: La metodología de diagnóstico completa para encontrar y solucionar todos los problemas de LCP.
• Optimiza la imagen LCP: Selección de formato de imagen, imágenes responsive, preloading y errores comunes con imágenes.
• Resource Load Duration: Después de que el navegador descubre el recurso, reduce cuánto tarda en descargarse mediante compresión, formatos modernos y optimización de CDN.
• Element Render Delay: Después de que el recurso se descarga, asegúrate de que el navegador pueda pintarlo inmediatamente limpiando el hilo principal.