Optimiza el retraso de carga del recurso LCP

Esta guía es parte del hub de Largest Contentful Paint (LCP). El Resource Load Delay es frecuentemente el mayor contribuyente a una mala puntuación de LCP, ¡especialmente en sitios SPA! 

Optimiza el Resource Load Delay del LCP

El Largest Contentful Paint (LCP) tiene cuatro subfases: TTFB, Resource Load Delay, Resource Load Duration y Element Render Delay. 

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

¿Qué es el Resource Load Delay?

El Resource Load Delay es el tiempo entre el TTFB y cuando el navegador inicia la descarga del recurso LCP. Básicamente, un navegador debe encolar un recurso LCP (la imagen LCP, por ejemplo)  lo antes posible. Si no se encola lo antes posible, lo más probable es que el navegador no pueda descubrirlo de inmediato o no lo reconozca como lo suficientemente importante.

Un valor alto aquí indica un problema de arquitectura donde el navegador no puede encontrar la URL del recurso en el payload HTML inicial. Este retraso de carga del recurso puede verse como el tiempo que el navegador pasa identificando que el recurso LCP es necesario y decidiendo obtenerlo.

También es importante entender que el Resource Load Delay ocurre antes de que el recurso se cargue realmente. Por eso no tiene nada que ver con imágenes responsivas o nuevos formatos de imagen como WebP o AVIF.

Para los elementos LCP basados en texto y renderizados con una fuente del sistema, este Resource Load Delay suele ser cero porque no hay que obtener ningún recurso externo. Los valores 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.

¿Cómo encuentra un navegador el elemento LCP?

Para reducir el Resource Load Delay, debes entender cómo los navegadores descubren los recursos (o al menos cómo descubren el elemento LCP). Los navegadores usan dos mecanismos: una ruta rápida y una ruta lenta. Primero tendrás que asegurarte de que el elemento LCP esté 'en la ruta rápida'.

• El DOM Parser (ruta lenta): Este es el analizador principal del navegador y es una bestia. Construye la página completa  leyendo el HTML, las hojas de estilo e interactuando con JavaScript. Esta es la ruta lenta porque puede retrasarse y detenerse si otros archivos se descargan y ejecutan primero, creando una cadena de dependencias que introduce retraso.
• El Preload Scanner (la ruta rápida): Como el DOM Parser es (relativamente) lento, los navegadores tienen un escáner secundario ultrarrápido que escanea la página muy rápido en busca de recursos descargables y no se detiene  por nada. Si encuentra etiquetas <script>, <img> sin lazy loading o <link>, las encola para descarga inmediatamente, antes de analizar el CSS o ejecutar JavaScript. Esta es la ruta óptima para cualquier recurso crítico.

Toda la estrategia para optimizar el Resource Load Delay se basa en un principio: asegura que la URL del recurso LCP sea descubrible lo antes posible por el preload scanner.

Eso significa 2 cosas para un elemento LCP:

1. Asegúrate de que el preload scanner pueda encontrarlo usando una etiqueta de imagen normal que no tenga la propiedad loading="lazy".
2. Asegúrate de que el preload scanner no priorice demasiados recursos menos importantes.

Por qué el Load Delay importa para las Core Web Vitals

Los desarrolladores principiantes suelen pensar que el LCP es un problema de "tamaño de archivo". Esto lleva a los equipos a centrarse en la compresión de imágenes, formatos de imagen modernos e imágenes responsivas. Esto es un error. Nuestra propia investigación sobre Core Web Vitals muestra que el mayor cuello de botella individual en el LCP es el TTFB (48%), seguido del Load Delay que ocupa el 24%. El Load Time solo ocupa el 10%, seguido del Render Delay que ocupa el 17%.

El truco es que el Load Delay es casi completamente solucionable, mientras que el TTFB siempre existirá. Eso hace que el Load Delay sea el elemento con mayor potencial de optimización.

Cómo detectar el Resource Load Delay

Para solucionar el Resource Load Delay, primero debes medirlo con precisión. El flujo de trabajo siempre es: verifica con CrUX, primero para definir el problema con datos de usuarios reales (RUM), y solo entonces pasa a Chrome DevTools para un análisis profundo.

Paso 1: Verifica con CrUX.

CrUX es la field data de usuarios reales de Google disponible públicamente para usuarios elegibles de Chrome, proporcionada como una vista móvil de 28 días de tus Core Web Vitals en el percentil 75. Te dice si un número es bueno o malo, pero no dice quién, qué ni por qué. Dado que Google confía en los datos de CrUX, esta es tu mejor fuente de verdad como punto de partida.

Ve a cruxvis.withgoogle.com, introduce tu sitio web, navega a Loading Performance y haz clic en las subpartes de imagen del  Largest Contentful Paint (LCP).

Paso 2: Analiza la field data (RUM)

RUM recopila las Core Web Vitals de todos tus usuarios reales y te ofrece una vista mucho más específica y detallada. Te dice el quién y el qué, segmentado como quieras (y esa información es oro), pero no el por qué.

Esta captura de pantalla de CoreDash te indica, por ejemplo, qué URLs sufren de Resource Load Delay (en verde).

Paso 3: Diagnostica 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 subpartes del LCP para obtener un valor preciso de Resource Load Delay. DevTools también es donde realizas un análisis del main thread para ver exactamente qué tareas se están ejecutando y potencialmente bloqueando el proceso de renderizado.

Guía paso a paso: escribimos un tutorial completo sobre este flujo de trabajo: Diagnostica el LCP con el panel Performance de Chrome DevTools. Cubre la configuración del throttling, la grabación de una traza y la lectura del valor exacto del Resource Load Delay desde el desglose del LCP.

Causas comunes y soluciones de alto impacto

Un alto Resource Load Delay se debe a una de dos cosas: el recurso LCP se descubre tarde, o se le asigna una baja prioridad de fetch. Aquí tienes los errores arquitectónicos más comunes y sus soluciones.

Causa: LCP cargado mediante CSS

El problema: El preload scanner no analiza los archivos CSS. Cuando tu imagen LCP se define con un background-image de CSS, 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, lee nuestra guía sobre cómo aplazar 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 inmediatamente. Puedes lograr el mismo resultado visual con CSS.

Ejemplo de implementación:

Antipatrón (No hagas esto):

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

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

Mejor práctica (Haz esto en su lugar):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        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 lo antes posible, lo cual minimiza su Load Delay.

Causa: Renderizado del lado del cliente e inyección de JavaScript

El problema: Las aplicaciones que usan frameworks de renderizado del lado del cliente (CSR) como React o Vue a menudo sirven un esqueleto (shell) HTML mínimo. El contenido real, incluida la etiqueta LCP <img>, solo se inserta en el DOM mediante JavaScript después de que se descargan, analizan y ejecutan los 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 render inicial del cliente al servidor.

• Server-Side Rendering (SSR) o Static Site Generation (SSG): Los 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. Configurar esto en true instruye al framework a añadir automáticamente la etiqueta <link rel="preload"> correcta y los atributos fetchpriority="high", asegurando que la imagen se descubra y se obtenga con la prioridad correcta.

Causa: Uso de 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 obtención de una imagen hasta que esté cerca del viewport. Aunque esta es la optimización correcta para imágenes below-the-fold, aplicarla a un elemento LCP 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 above-the-fold. 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 el lazy loading a todas las imágenes. Es fundamental configurar estas herramientas para excluir la imagen LCP de este comportamiento. Esto a menudo implica crear una regla de exclusión para la primera o las dos primeras imágenes en 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 los recursos no críticos pero que consumen mucho ancho de banda, como iconos de encabezado o scripts de widgets de chat, se colocan más arriba en el <body> que el elemento LCP, se descubren y encolan para su descarga primero. Esto consume el ancho de banda de red inicial 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 por al menos un viaje de ida y vuelta a 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 para el elemento LCP aparezca lo antes posible dentro de la etiqueta <body>.
• Desprioriza las imágenes no críticas: Para imágenes no esenciales que deben aparecer temprano en el código HTML (como los iconos en un encabezado), aplica loading="lazy". Esto le dice al preload scanner que las ignore, preservando la cola de descarga para el elemento LCP.
• Aplaza los scripts no esenciales: Los scripts para analíticas, anuncios o widgets de redes sociales rara vez son críticos para el render inicial. Mueve sus etiquetas <script> al final del <body> o usa el atributo defer. Esto evita que bloqueen el parser o compitan por el ancho de banda 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 darle al navegador instrucciones más explícitas sobre cómo obtenerlo. Estos hints proporcionan un control preciso sobre el descubrimiento y la priorización.

Forzar un 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 analizador 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 de fondo CSS o imágenes LCP ubicadas profundamente en el DOM. Para detalles completos de implementación y ejemplos, lee nuestra guía dedicada sobre cómo precargar la imagen LCP.

Mecanismo

Cuando se coloca un enlace preload en el <head> del documento HTML, el preload scanner lo identifica y encola inmediatamente el recurso especificado para su descarga. Esto es ideal para recursos como fuentes cargadas mediante @font-face en una hoja de estilo externa, LCPs de CSS background-image (aunque se prefiere usar una etiqueta <img>), o una imagen LCP que se encuentra en lo profundo de una estructura DOM compleja.

Precarga responsiva

Se requiere un detalle de implementación crítico al precargar imágenes responsivas. Para asegurar que el navegador precargue la imagen del tamaño correcto para el viewport del usuario y evite una doble descarga inútil, la etiqueta <link rel="preload"> debe incluir los atributos imagesrcset e imagesizes que reflejen perfectamente los atributos de la etiqueta <img> correspondiente.

Ejemplo de precarga responsiva:

<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="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Posible problema

La precarga resuelve el tiempo de fetch (Load Delay y Load Duration) pero no el tiempo de pintado. Si el main thread está bloqueado por un JavaScript pesado o un CSS render blocking cuando llega la imagen precargada, la imagen todavía tendrá que esperar para ser renderizada, lo que puede desplazar el cuello de botella del Load Delay al Element Render Delay.

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 descarga del navegador.

Cómo funciona la prioridad del navegador

Cuando el navegador descubre recursos durante la carga de la página, le asigna a cada uno un nivel de prioridad interno. Por defecto, las imágenes en el viewport comienzan en prioridad "Baja" (Low) y luego se actualizan a "Alta" (High) una vez que el navegador completa el layout 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" omite este proceso por completo al establecer la imagen en prioridad "Alta" desde el momento en que se descubre. 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 tienen propósitos diferentes pero complementarios. preload afecta cuándo se descubre un recurso y se añade a la cola. fetchpriority afecta su nivel de prioridad una vez que está en la cola. Entender esta distinción es crítico: preload soluciona el descubrimiento tardío, mientras que fetchpriority soluciona la priorización baja. 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, lee nuestro artículo sobre priorización de recursos.

Mejor práctica para el LCP

Para la imagen LCP, la estrategia óptima es usarlos juntos. Primero, asegura un descubrimiento temprano, ya sea colocando la etiqueta <img> al principio del 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 red contra otros recursos como hojas de estilo o fuentes.

Ejemplo:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Cuándo usar fetchpriority="low"

El atributo fetchpriority no solo sirve para aumentar la prioridad. También puedes usar fetchpriority="low" para despriorizar recursos no críticos que compiten por el ancho de banda con la imagen LCP. Los candidatos comunes incluyen imágenes above-the-fold 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 de la competencia, creas más margen de ancho de banda para la imagen LCP.

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

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

Impacto comprobado

En un caso de estudio de Google Flights, añadir fetchpriority="high" a la imagen de fondo LCP mejoró el tiempo del LCP de 2,6 segundos a 1,9 segundos, una mejora de 700 ms.

Optimizando 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 a 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 establecimiento de la conexión es un contribuyente directo al Resource Load Delay para activos cross-origin.

Las soluciones

• preconnect: Este hint instruye al navegador a realizar el establecimiento completo de la conexión (DNS, TCP y TLS) para un origen de terceros especificado en segundo plano, con antelación. Cuando el recurso se solicita realmente, la conexión ya está lista (warm), eliminando la latencia de establecimiento. Esto es muy efectivo y recomendado para los uno o dos dominios de terceros más críticos que sirven recursos LCP.
• 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 una mayor compatibilidad con navegadores y es útil como fallback o para dominios de terceros menos críticos.

Mejor práctica de implementación

Para asegurar la máxima compatibilidad, proporciona ambos hints. El navegador usará preconnect si es compatible y hará fallback a dns-prefetch si no lo es. El atributo crossorigin es esencial para los recursos obtenidos 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 optimizar el LCP

Para evitar un mal uso y aclarar los distintos roles de estos poderosos hints, la siguiente tabla proporciona un resumen comparativo.

Estrategias holísticas y orientadas al futuro

Más allá de los resource hints, decisiones arquitectónicas más amplias pueden reducir aún más el Resource Load Delay.

El rol de un CDN moderno

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

• Reducción de la sobrecarga de conexión: Al distribuir los activos en una red global de servidores, un CDN acerca geográficamente el contenido al 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 componentes del tiempo de establecimiento de la conexión. Para una imagen LCP alojada en un CDN, esto reduce directamente su Load Delay.
• CDNs de imágenes: Los CDNs de imágenes especializados ofrecen un doble beneficio. Proporcionan la ventaja de proximidad de un CDN estándar y también automatizan muchas optimizaciones complejas que reducen la Resource Load Duration, como el redimensionamiento de imágenes sobre la marcha, la compresión y la conversión a formatos modernos como AVIF y WebP.
• Protocolos avanzados: Muchos CDNs modernos usan HTTP/3, que utiliza QUIC en lugar de TCP. HTTP/3 reduce el tiempo de establecimiento de conexión y mitiga el head-of-line blocking, lo que lleva a una entrega de recursos más rápida y eficiente en general.

Eliminación total del retraso con Speculation Rules

Las Speculation Rules permiten a los navegadores hacer prefetch o prerender de páginas web basándose en la navegación predicha del usuario. El prefetch elimina efectivamente la subparte Time to First Byte del LCP y no tiene impacto en el Resource Load Delay. El prerendering renderiza la siguiente página en una pestaña oculta y descarga todos los recursos de la página. Esto elimina todos los retrasos de carga para el elemento LCP, como se muestra en este ejemplo de desglose de LCP de una página prerenderizada.

Mecanismo

Esta API permite a los desarrolladores informar declarativamente al navegador sobre a qué URLs es probable que un usuario navegue a continuación. Basándose en estas reglas, el navegador puede elegir hacer prerender de una página objetivo en una pestaña oculta en segundo plano antes de que el usuario siquiera haga clic en el enlace.

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 ha sido completamente cargada y renderizada 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.

Ejemplo de caso de uso

En una página de categoría de e-commerce, las speculation rules podrían usarse para prerenderizar las páginas de detalle de producto para los primeros artículos de la lista. Cuando un usuario hace clic en uno de estos productos, la página aparece al instante.

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

Estas optimizaciones tienen un impacto medible en el mundo real.

• Caso 1: El poder transformador de la precarga: 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 peticiones, causando que el Resource Load Delay representara un asombroso 75% del tiempo total del LCP. Al implementar un solo hint <link rel="preload"> para que la imagen fuera descubrible temprano, el Resource Load Delay se redujo a solo un 2% del tiempo del LCP. Esto demuestra cómo una simple corrección arquitectónica puede resolver un cuello de botella de rendimiento masivo.
• Caso 2: El antipatrón loading="lazy" en el mundo real: Un desarrollador en Stack Overflow reportó un LCP en escritorio con un desconcertante Load Delay de 1.430 ms a pesar de una red rápida. La causa se rastreó hasta un plugin de optimización de imágenes que aplicaba incorrectamente el lazy loading a la imagen LCP al reemplazar su atributo src por un SVG placeholder transparente. La solución definitiva fue desactivar este comportamiento para el elemento LCP, permitiendo que se descubriera y cargara de forma eager. Esto ilustra cómo las herramientas de terceros pueden introducir inadvertidamente severos retrasos de carga.
• Caso 3: El aumento de rendimiento con fetchpriority: El caso de estudio de Google Flights proporciona evidencia clara sobre el impacto de la priorización explícita. Simplemente añadiendo fetchpriority="high" a la imagen de fondo LCP de la página, la puntuación del LCP mejoró en 700 ms, bajando de 2,6 segundos a 1,9 segundos. 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 red.

Inspección de red en Chrome DevTools: Usa el atajo Ctrl + Shift + I para abrir las Developer Tools de Chrome, luego selecciona la pestaña "Network" y recarga la página. Mira la secuencia de carga. Tu recurso LCP debería ser uno de los primeros elementos encolados para descarga. Si se queda atrás respecto a 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 se ha optimizado.

Usa datos de Real User Monitoring (RUM): Las herramientas de Real User Monitoring a menudo registran datos de atribución de LCP. Con RUM, puedes visualizar el desglose de las subpartes 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 timing de los recursos no son óptimos. Hay, en esencia, dos formas directas de arreglar esto: priorizar el recurso LCP o despriorizar recursos que no son LCP. Vamos a explorar algunos patrones comunes:

Consejo de LCP: Entiende el Preload Scanner: Los navegadores modernos usan un mecanismo llamado preload scanner, que escanea rápidamente el HTML y encola recursos para su descarga. Si un recurso no puede ser encolado por el preload scanner, tendrá que esperar al DOM parser, que es más lento, resultando en retrasos. Asegurar que tus recursos LCP sean descubribles por el preload scanner marca una gran diferencia a la hora de reducir el Load Delay.

1. Optimiza la estructura HTML

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

• Haz lazy loading en imágenes poco importantes u ocultas: A veces hay imágenes (por ejemplo, banderas para versiones de idiomas de tu sitio o imágenes en el menú) en la parte superior del HTML de tu sitio. Estas imágenes no son ni remotamente tan importantes como el elemento LCP. Al aplicar lazy loading a estas imágenes, el preload scanner las ignora y se encolan un poco más tarde durante el proceso de carga.
• Mueve los scripts poco importantes al final de la página: Mueve los scripts que son absolutamente irrelevantes para la carga inicial al final de la página para evitar que retrasen recursos críticos. Por ejemplo, un widget de chat. ¡Nadie en la historia de internet ha necesitado chatear antes de que la página sea visible!

2. Evita las imágenes de fondo

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

3. Usa Fetch Priority

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

Fetchpriority suele ser menos intrusivo (y menos efectivo) que la precarga 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, hojas de estilo o scripts no bloqueantes.

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

4. Implementa la precarga

La precarga cambia el orden en el que el preload scanner encola los archivos. Coloca la etiqueta <link rel="preload"> en el head de la página para instruir al navegador a obtener 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 encolan más tarde) o incluso para precargar recursos que aún no se referencian en el HTML (como en algunos sliders). Para la 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 encolan antes que el recurso LCP, y con razón. Sin las 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 un lazy loading eficiente

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

• Carga con eager el elemento LCP: Si el elemento LCP tiene lazy loading, no será encolado por el preload scanner y cargará mucho más tarde, impactando negativamente el rendimiento.
• Haz lazy loading en imágenes del viewport: Para las imágenes que están en el viewport visible pero no son recursos LCP, usa loading="lazy" para encolarlas para descarga un poco más tarde. Esto reduce la competencia de ancho de banda con el recurso LCP.
• Evita hacer lazy loading en imágenes offscreen: Las imágenes que no están en el viewport visible no desencadenarán ninguna descarga, eliminando por completo la competencia por el ancho de banda.

7. Caché del navegador

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

• Cachea los recursos competidores: Aunque cachear el recurso LCP en sí es una gran estrategia, el caché del navegador mejora los retrasos de carga del recurso LCP almacenando recursos de red que podrían competir con el recurso LCP o retrasarlo, como scripts, hojas de estilo e imágenes.
• Reduce la carga del servidor: El caché disminuye el número de peticiones 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

Las Speculation Rules permiten a los navegadores hacer prefetch o prerender de páginas web basándose en la navegación predicha del usuario. El prefetch elimina efectivamente la subparte Time to First Byte del LCP y no tiene impacto en el Resource Load Delay. El prerendering renderiza la siguiente página en una pestaña oculta y descarga todos los recursos de la página. Esto elimina todos los retrasos de carga 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: Sigue optimizando el LCP

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

• Soluciona e identifica problemas de LCP: La metodología de diagnóstico completa para encontrar y arreglar todos los problemas de LCP.
• Optimiza la imagen LCP: Selección de formato de imagen, imágenes responsivas, precarga y errores de imagen comunes.
• Resource Load Duration: Después de que el navegador descubre el recurso, reduce cuánto tarda en descargar mediante compresión, formatos modernos y optimización CDN.
• Element Render Delay: Después de que se descarga el recurso, asegura que el navegador pueda pintarlo de inmediato limpiando el main thread.