Optimiza el retraso de carga del recurso LCP

Esta guía es parte del hub de Largest Contentful Paint (LCP). El Resource Load Delay suele ser el factor individual que más contribuye a una mala puntuación de LCP, ¡especialmente en sitios SPA! 

Optimiza el Resource Load Delay del LCP

Largest Contentful Paint (LCP) es una de las cuatro subfases del LCP: 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 si fuera texto. Debes monitorizar los tipos de elementos de LCP en tus datos de RUM; de lo contrario, vas a ciegas.

¿Qué es el Resource Load Delay?

El Resource Load Delay es el tiempo que transcurre entre el TTFB y el momento en que el navegador inicia la descarga del recurso del LCP. Básicamente, el navegador debería encolar el recurso del LCP (la imagen del LCP, por ejemplo) lo antes posible. Si no lo hace, probablemente se deba a que el navegador no puede descubrirlo de inmediato o no lo reconoce como suficientemente importante.

Un valor alto aquí indica un problema arquitectónico: el navegador no encuentra la URL del recurso en el payload HTML inicial. Este Resource Load Delay representa el tiempo que el navegador tarda en identificar que necesita el recurso del LCP y en decidir descargarlo.

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 adaptables o nuevos formatos de imagen como WebP o AVIF.

En los elementos de LCP basados en texto y renderizados con una tipografía del sistema, este Resource Load Delay suele ser cero porque no hay que descargar ningún recurso externo. Los valores de Resource Load Delay más altos se dan específicamente en elementos de LCP que dependen de un recurso de red externo, como una imagen o un archivo de vídeo.

¿Cómo encuentra el navegador el elemento LCP?

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

• El parser de DOM (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 por la descarga y ejecución de otros archivos, lo que crea una cadena de dependencias que introduce retrasos.
• El preload scanner (ruta rápida): Como el parser de DOM es (relativamente) lento, los navegadores tienen un escáner secundario ultrarrápido que analiza la página a gran velocidad en busca de recursos descargables y no se detiene ante nada. Si encuentra etiquetas <script>, <img> no diferidas (non-lazy) o <link>, las encola para descargar de inmediato, antes de analizar el CSS o ejecutar el 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: asegurar que la URL del recurso del LCP sea descubrible lo antes posible por el preload scanner.

Para un elemento LCP, eso significa dos cosas:

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

Por qué el Load Delay es importante 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 modernos e imágenes adaptables. Esto es un error. Nuestra propia investigación sobre Core Web Vitals demuestra que el mayor cuello de botella individual en el LCP es el TTFB (48%), seguido por el Load delay, que representa el (24%); el Load time solo ocupa el 10%, seguido por el Render delay, con un 17%.

El truco está en que el Load delay es casi totalmente solucionable, mientras que el TTFB siempre existirá. Eso convierte al Load delay en 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 es siempre el mismo: consultar CrUX para definir el problema con datos de usuarios reales (RUM) y solo después pasar a Chrome DevTools para un análisis profundo.

Paso 1: Comprobar con CrUX.

CrUX es el field data de usuarios reales de Google disponible públicamente, procedente de usuarios de Chrome aptos, presentado como una vista móvil de 28 días de tus Core Web Vitals en el percentil 75. Te dice si una cifra es buena o mala, pero no indica quién, qué ni por qué. Dado que Google se basa en los datos de CrUX, esta es tu mejor fuente de información como punto de partida.

Ve a cruxvis.withgoogle.com, introduce tu sitio web, navega a Loading Performance y haz clic en Largest Contentful Paint (LCP) image subparts

Paso 2: Analizar 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 quién y qué, segmentado como quieras (y esa información vale oro), pero no por qué.

Paso 3: Diagnosticar con DevTools

Una vez que tus datos de RUM hayan identificado una página de destino y un elemento LCP, utilizas 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 el lugar donde realizas un análisis del main thread para ver exactamente qué tareas se están ejecutando y si están bloqueando el proceso de renderizado.

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

El panel Performance de Chrome DevTools es una herramienta indispensable para analizar el LCP y cuantificar el Load Delay.

1. Configuración y preparación:

• Abre Chrome DevTools haciendo clic derecho en la página y seleccionando "Inspect" 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é activada 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 reales de los usuarios, aplica throttling de CPU y red. Una desaceleración de "4x slowdown" para la CPU y un perfil de red "Fast 3G" o "Slow 4G" son puntos de partida comunes para las pruebas en móviles.

2. Grabar un perfil de rendimiento:

• Haz clic en el botón "Record and reload page" (un icono de flecha circular) en el panel Performance. Esto iniciará una grabación, recargará la página y detendrá la grabación una vez que la página se haya cargado por completo.

3. Análisis e interpretación:

• Track Timings: En la vista de la línea de tiempo principal, localiza el track Timings. Verás un marcador etiquetado como 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 del LCP.
• Desglose del LCP por fases: Haz clic en el marcador LCP en el track Timings. En la pestaña Summary de la parte inferior del panel, encontrarás un desglose detallado del tiempo del LCP. Este desglose muestra explícitamente la duración de cada una de las cuatro subpartes, incluido 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 main thread: Mientras examinas la línea de tiempo, busca en el track Main cualquier long task (bloques de actividad marcados con un triángulo rojo). Si estas long tasks ocurren después de que el recurso del LCP haya terminado de cargarse pero antes del marcador LCP, es probable que estén contribuyendo al Element Render Delay, un problema relacionado pero diferente.

Causas comunes y soluciones de alto impacto

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

Causa: LCP cargado a través de CSS

El problema: El preload scanner no analiza los archivos CSS. Cuando tu imagen de 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 del archivo CSS, descargar dicho archivo, construir el CSSOM y aplicar el estilo. Esta cadena de dependencias causa directamente un Resource Load Delay alto. Para saber más sobre este patrón, consulta nuestra guía sobre diferir imágenes de fondo.

La solución: La implementación correcta es evitar el uso de background-image para cualquier elemento de LCP crítico. En su lugar, usa una etiqueta <img> estándar. 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:

Antipatrón (no hagas esto):

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

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

Práctica recomendada (haz esto en su lugar):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Texto alternativo descriptivo para la imagen del 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 del resto del contenido */
    }
    

Esta implementación proporciona el mismo resultado visual, pero hace que la imagen del LCP sea descubrible lo antes posible, lo que minimiza su Load Delay.

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

El problema: Las aplicaciones que utilizan frameworks de client-side rendering (CSR) como React o Vue suelen servir un esqueleto 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 descarguen, analicen y ejecuten los grandes paquetes (bundles) del framework. Este proceso oculta fundamentalmente el recurso del LCP al preload scanner, lo que genera una alta latencia de descubrimiento.

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

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

Causa: Uso de loading="lazy" en la imagen del LCP

El problema: Este es un error frecuente y de gran 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. Aunque esta es la optimización correcta para las imágenes que están debajo de la línea de flotación, aplicarla a un elemento de LCP que está por encima de la línea de flotación 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 Resource Load Delay alto.

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

• Elimina loading="lazy" de la imagen del LCP: Cualquier imagen que tenga probabilidades de ser 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 el contenido crítico que está por encima de la línea de flotación. 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 diversos plugins de optimización de imágenes aplican automáticamente lazy loading a todas las imágenes. Es fundamental configurar estas herramientas para excluir la imagen del LCP de este comportamiento. Esto suele implicar la creación de una regla de exclusión para la primera o segunda imagen 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 que no son críticos pero consumen mucho ancho de banda (como los iconos de la cabecera o los scripts del widget de chat) se colocan en el <body> por encima del elemento LCP, se descubren y se encolan para su descarga primero. Esto consume el ancho de banda inicial de la red y puede retrasar la descarga del recurso del 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 14 KB), su descubrimiento se retrasará al menos un viaje de ida y vuelta de 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 arriba posible dentro de la etiqueta <body>.
• Desprioriza imágenes no críticas: Para imágenes no esenciales que deban aparecer al principio del código HTML (como los iconos de una cabecera), aplica loading="lazy". Esto le indica al preload scanner que las omita, reservando la cola de descarga para el elemento LCP.
• Difiere scripts no esenciales: Los scripts de analítica, anuncios o widgets de redes sociales rara vez son críticos para el renderizado inicial. Mueve sus etiquetas <script> al final del <body> o utiliza el atributo defer. Esto evita que bloqueen el parser o compitan por el ancho de banda de red con el recurso del LCP.

Priorización avanzada con Resource Hints

Una vez que el recurso del 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 prioridad alta, incluso si el parser principal aún no lo puede descubrir. Colocarlo en el <head> de tu HTML es la forma más directa de solucionar los problemas de descubrimiento tardío de recursos como fuentes, imágenes de fondo CSS o imágenes de LCP ubicadas a gran profundidad en el DOM. Para obtener detalles completos de implementación y ejemplos, consulta nuestra guía dedicada sobre cómo precargar la imagen del 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, imágenes de LCP cargadas mediante un background-image de CSS (aunque se prefiere usar una etiqueta <img>), o una imagen de LCP que se encuentra a gran profundidad en una estructura DOM compleja.

Precarga adaptable

Se requiere un detalle de implementación crítico al precargar imágenes adaptables. Para garantizar que el navegador precargue la imagen con el tamaño correcto para el viewport del usuario y evitar una descarga doble innecesaria, la etiqueta <link rel="preload"> debe incluir los atributos imagesrcset e imagesizes que imiten a la perfección los atributos de la etiqueta <img> correspondiente.

Ejemplo de precarga adaptable:

<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 problema

La precarga soluciona el momento de descarga (fetch timing) (Load Delay y Load Duration) pero no el momento de pintado (paint timing). Si el main thread está bloqueado por un JavaScript pesado o por un CSS render blocking cuando llega la imagen precargada, esta todavía tendrá que esperar para renderizarse, lo que puede trasladar 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 indica 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, asigna a cada uno un nivel de prioridad interno. Por defecto, las imágenes en el viewport comienzan con una prioridad "Low" (Baja) y más tarde se actualizan a "High" (Alta) una vez que el navegador completa el diseño (layout) y determina que son visibles. Esta actualización requiere que el navegador descargue y analice primero el CSS, lo que genera un retraso. El atributo fetchpriority="high" evita este proceso por completo al establecer la imagen con prioridad "High" desde el momento en que se descubre. Esto tiene un impacto especial en las imágenes de 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 influye en cuándo se descubre y se añade un recurso a la cola. fetchpriority influye en su nivel de prioridad una vez que está en la cola. Entender esta distinción es clave: preload soluciona el descubrimiento tardío, mientras que fetchpriority soluciona la baja priorización. Para muchas imágenes de LCP que ya están en el HTML, fetchpriority por sí solo puede ser suficiente. Para obtener una guía completa sobre cómo interactúan, consulta nuestro artículo sobre priorización de recursos.

Práctica recomendada para el LCP

Para la imagen del LCP, la estrategia óptima es usarlos juntos. Primero, asegura un descubrimiento temprano 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 garantiza que el recurso no solo se descubra pronto, sino que también reciba la mayor prioridad posible para ganar la competencia por el ancho de banda de la red frente a otros recursos como hojas de estilo o fuentes.

Ejemplo:

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

Cuándo usar fetchpriority="low"

El atributo fetchpriority no sirve solo para aumentar la prioridad. También puedes usar fetchpriority="low" para despriorizar recursos no críticos que compitan por el ancho de banda con la imagen del LCP. Los candidatos habituales incluyen imágenes por encima de la línea de flotación que no sean el elemento LCP (como iconos pequeños o avatares en la cabecera) y recursos precargados que sean necesarios pero no urgentes. Al reducir explícitamente la prioridad de estos recursos competidores, dejas más margen de ancho de banda libre para la imagen del LCP.

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

<!-- Imagen no crítica por encima de la línea de flotación: prioridad baja -->
<img src="avatar.jpg" fetchpriority="low" alt="Avatar del autor" width="48" height="48">

Impacto demostrado

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

Optimizar las conexiones con terceros: preconnect y dns-prefetch

El problema

Si tu recurso del LCP está alojado en un dominio de terceros (como una 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 incluye una resolución DNS, un protocolo de enlace TCP (handshake) y una negociación TLS, pasos que deben completarse antes de que se pueda descargar el primer byte del recurso. Este tiempo de establecimiento de la conexión contribuye directamente al Resource Load Delay de los recursos de origen cruzado (cross-origin).

Las soluciones

• preconnect: Este hint indica al navegador que realice todo el proceso de conexión (DNS, TCP y TLS) con un origen de terceros especificado en segundo plano y de forma anticipada. Cuando el recurso se solicita realmente, la conexión ya está establecida (caliente), eliminando la latencia de configuración. Esto es muy eficaz y se recomienda para los uno o dos dominios de terceros más críticos que sirvan recursos del LCP.
• dns-prefetch: Este es un hint más ligero que solo realiza la resolución DNS de un dominio. Ahorra menos tiempo que preconnect, pero tiene mayor soporte en navegadores y es útil como fallback o para dominios de terceros menos críticos.

Práctica recomendada de implementación

Para garantizar la máxima compatibilidad, proporciona ambos hints. El navegador utilizará preconnect si es compatible y recurrirá a dns-prefetch como fallback si no lo es. El atributo crossorigin es fundamental para los recursos que se descargan mediante 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 evitar un mal uso y aclarar las funciones específicas de estos potentes hints, la siguiente tabla ofrece un resumen comparativo.

Estrategias globales y de 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 papel de una CDN moderna

Una Content Delivery Network (CDN) es una tecnología fundamental para el rendimiento web que, de forma indirecta pero significativa, reduce el Resource Load Delay, en especial para los recursos del LCP.

• Reducción de la sobrecarga de conexión: Al distribuir los recursos a través de una red global de servidores, una CDN coloca el contenido geográficamente más cerca del usuario. Esto reduce de forma inherente el tiempo de viaje de ida y vuelta (RTT) necesario para la resolución DNS, el protocolo de enlace TCP y la negociación TLS, componentes todos ellos del tiempo de configuración de la conexión. Para una imagen de LCP alojada en una CDN, esto reduce directamente su Load Delay.
• CDN de imágenes: Las CDN de imágenes especializadas ofrecen una doble ventaja. Aportan el beneficio de proximidad de una CDN estándar al tiempo que automatizan muchas optimizaciones complejas que reducen el Resource Load Duration, como el cambio de tamaño de imagen sobre la marcha, la compresión y la conversión a formatos modernos como AVIF y WebP.
• Protocolos avanzados: Muchas CDN modernas utilizan HTTP/3, que emplea 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 se traduce en una entrega de recursos más rápida y eficiente en general.

Eliminar el retraso por completo con Speculation Rules

La API Speculation Rules puede eliminar por completo el retraso del LCP en las navegaciones posteriores.

Mecanismo

Esta API permite a los desarrolladores informar de manera declarativa al navegador sobre las URL a las que es probable que el usuario navegue a continuación. Según estas reglas, el navegador puede elegir realizar un prerender de la página de destino en una pestaña oculta en segundo plano antes de que el usuario haga clic en el enlace.

Impacto en el LCP

Cuando el usuario hace clic en el enlace de una página precargada mediante prerender, la navegación es prácticamente instantánea. La página ya se ha cargado y renderizado por completo en segundo plano. Para esta navegación, el TTFB, el Resource Load Delay, el Resource Load Duration y el Element Render Delay se reducen de forma efectiva casi a cero desde la perspectiva del usuario.

Caso de uso de ejemplo

En una página de categoría de comercio electrónico, se podrían utilizar speculation rules para prerenderizar las páginas de detalles de producto de 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 real y medible.

• Caso 1: El poder transformador de la precarga: Un experimento realizado por DebugBear en una página con un Load Delay alto ofrece un ejemplo espectacular. La imagen del LCP estaba oculta en una cadena de peticiones, lo que hacía que el Resource Load Delay representara un asombroso 75% del tiempo total del LCP. Al implementar un único hint <link rel="preload"> para que la imagen se descubriera temprano, el Resource Load Delay se redujo a solo el 2% del tiempo del LCP. Esto demuestra cómo una solución arquitectónica sencilla puede resolver un cuello de botella de rendimiento masivo.
• Caso 2: El antipatrón de loading="lazy" en el mundo real: Un desarrollador en Stack Overflow informó de un LCP en escritorio con un desconcertante retraso de carga de 1.430 ms a pesar de contar con una red rápida. La causa se atribuyó a un plugin de optimización de imágenes que aplicaba incorrectamente el lazy loading a la imagen del LCP reemplazando su atributo src por un SVG de marcador de posición transparente. La solución definitiva fue desactivar este comportamiento para el elemento de LCP, lo que permitió descubrirlo y cargarlo de forma activa (eager). Esto ilustra cómo las herramientas de terceros pueden introducir inadvertidamente graves retrasos de carga.
• Caso 3: El impulso de rendimiento con fetchpriority: El caso de estudio de Google Flights ofrece pruebas claras del impacto de la priorización explícita. Con solo añadir fetchpriority="high" a la imagen de fondo del LCP de la página, la puntuación de LCP mejoró en 700 ms, pasando de 2,6 a 1,9 segundos. Esto demuestra que incluso cuando un recurso es descubrible, indicarle al navegador su alta importancia es un paso fundamental 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 desarrollador de Chrome, selecciona la pestaña "Network" y recarga la página. Observa la secuencia de carga. El recurso de tu LCP debería ser uno de los primeros elementos encolados para su descarga. Si se queda por detrás de otros elementos, existe un problema de retraso de carga del recurso. 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 suelen registrar datos de atribución del LCP (LCP attribution data). Con RUM, puedes visualizar el desglose de las subpartes del LCP (a lo largo del tiempo o por página), lo que te dará una imagen clara del Load Delay de los elementos de LCP en todo tu sitio o por página. El ejemplo siguiente muestra un desglose global del LCP junto con su correspondiente Load Delay.

Cómo mejorar el Load Delay

El Resource Load Delay se produce cuando el orden de descarga y el tiempo de los recursos no son óptimos. Básicamente, existen dos formas directas de solucionarlo: priorizar el recurso del LCP o despriorizar los recursos que no sean del LCP (Non-LCP). Exploremos algunos patrones comunes:

Consejo sobre LCP: Comprende el preload scanner: Los navegadores modernos utilizan un mecanismo llamado preload scanner que analiza rápidamente el HTML y encola recursos para su descarga. Si un recurso no se puede encolar mediante el preload scanner, tendrá que esperar al analizador DOM (DOM parser), que es más lento, lo que provocará retrasos. Asegurarse de que los recursos del LCP sean descubribles por el preload scanner puede marcar una gran diferencia a la hora de reducir el Load Delay.

1. Optimizar la estructura HTML

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

• Aplica lazy loading a imágenes poco importantes u ocultas: A veces, hay imágenes (como banderas para las versiones de idioma del sitio o imágenes en el menú) que se encuentran en la parte superior del HTML de tu página. Estas imágenes no son, ni mucho menos, tan importantes como el elemento LCP. Al aplicarles lazy loading, el preload scanner las omite y se encolan un poco más tarde durante el proceso de carga.
• Mueve los scripts poco importantes al final de la página: Lleva los scripts que no sean en absoluto importantes 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 sea visible!

2. Evitar imágenes de fondo

Las imágenes de fondo son invisibles para el preload scanner, lo que significa que siempre se encolarán a través del parser de DOM, que es mucho más lento. Para evitar este retraso, utiliza una etiqueta <img> normal 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 dapat detectar y encolar la imagen de inmediato.

3. Usar 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 se cargan con una prioridad baja o media por defecto. Durante la fase de diseño (layout), el navegador sube la prioridad de los elementos visibles a alta. Al configurar fetchpriority="high", la descarga comienza de inmediato con una prioridad alta, lo que garantiza un LCP más rápido.

Fetchpriority suele ser menos intrusivo (y menos eficaz) 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 hace que sea más importante que, por ejemplo, las hojas de estilo o los scripts no bloqueantes.

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

4. Implementar la precarga

La precarga cambia el orden en que el preload scanner encola los archivos. 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 del LCP, lo antes posible. Las precargas se pueden usar para descargar recursos a los que se hace referencia más adelante en el HTML (y que, por lo tanto, se encolan más tarde) o incluso para precargar recursos que aún no se mencionan en el HTML (como ocurre con algunos carruseles/sliders). Para una máxima eficacia, se recomienda colocar las precargas 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. Optimizar estilos

Las hojas de estilo se encolan normalmente antes del recurso del LCP, y con razón. Sin ellas, el navegador no sabrá qué aspecto tendrá la página y no podrá iniciar la fase de renderizado. Sin embargo, un tamaño excesivo de CSS y una cantidad desmesurada de hojas de estilo competirán con el recurso del LCP por el ancho de banda inicial.

6. Implementar 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 valor predeterminado del navegador) para el recurso del LCP, mientras aplicas loading="lazy" para las imágenes fuera de pantalla.

• Carga activa (Eager) del elemento LCP: Si el elemento LCP se carga de forma diferida (lazy), el preload scanner no lo encolará y se cargará mucho más tarde, afectando negativamente al rendimiento.
• Lazy-load de imágenes en el viewport: Para las imágenes que están en el viewport visible pero no son recursos de LCP, utiliza loading="lazy" para encolar su descarga un poco más tarde. Esto reduce la competencia por el ancho de banda con el recurso del LCP.
• Evita el lazy loading de imágenes fuera de pantalla: Las imágenes que no están en el viewport visible no iniciarán la descarga en absoluto, eliminando por completo la competencia por el ancho de banda.

7. Caché del navegador

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

• Caché de recursos competidores: Aunque almacenar en caché el propio recurso del LCP es una gran estrategia, la caché del navegador reduce el Load Delay del LCP al almacenar recursos de red que podrían competir con él o retrasarlo, como scripts, hojas de estilo e imágenes.
• Reducción de la carga del servidor: La caché disminuye la cantidad 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. Usar Speculation Rules

Speculation Rules permite a los navegadores realizar prefetch o prerender de páginas web basándose en la navegación prevista del usuario. El prefetch elimina eficazmente la subparte del LCP correspondiente a Time to First Byte y no tiene impacto en el Resource Load Delay. El prerender 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 del LCP de una página prerenderizada.

9. Evitar el client-side rendering

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:

• Identificar y solucionar problemas de LCP: La metodología de diagnóstico completa para encontrar y solucionar todos los problemas de LCP.
• Optimizar la imagen del LCP: Selección del formato de imagen, imágenes adaptables, precarga y errores comunes de las imágenes.
• Resource Load Duration: Después de que el navegador descubra el recurso, reduce el tiempo que tarda en descargarse mediante compresión, formatos modernos y optimización de CDN.
• Element Render Delay: Después de descargar el recurso, asegúrate de que el navegador pueda pintarlo de inmediato liberando el main thread.