LCP request discovery en Lighthouse: checks y el fix

¿Qué te dice LCP request discovery sobre la imagen del LCP?

LCP request discovery es el insight de Lighthouse 13 que sustituyó a "Preload Largest Contentful Paint image" y "Largest Contentful Paint image was lazily loaded". Comprueba si la imagen del LCP, la foto grande que esperan los visitantes, se descubre desde el HTML: si el navegador pudo empezar a descargarla en cuanto llegó el HTML, con prioridad alta. El fix: la foto como un <img> en el HTML, sin loading="lazy", con fetchpriority="high".

¿Solo buscas el fix rápido? Salta a WordPress, page builders, Shopify o Next.js.

¿Qué significan los tres checks de LCP request discovery?

En Lighthouse 13 y PageSpeed Insights el aviso dice: "Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading". Debajo aparecen tres checks, cada uno en verde o en rojo.

El aviso para la página de inicio de un hotel cuya foto grande tiene loading="lazy". Lighthouse 13.6 con throttling de DevTools.

• fetchpriority=high should be applied: el navegador pidió la imagen del LCP sin fetchpriority="high". Cuando la foto llegó mediante un preload, el check dice "fetchpriority=high should be applied to the image preload request": el preload también lo necesita. Cuando pasa, dice "fetchpriority=high applied".
• Request is discoverable in initial document: la URL de la foto está en el propio HTML, en un <img> o en un preload, donde el preload scanner (la parte del navegador que lee el HTML por anticipado) la encuentra. Una imagen de fondo en una hoja de estilos, un slider que monta sus slides con JavaScript o un script de lazy loading que movió la URL a data-src ponen este check en rojo.
• LCP resources shouldn’t use loading=lazy: la foto tiene loading="lazy", por lo que el navegador solo la pide cuando el layout confirma que está en pantalla.

Un solo check en rojo pone el aviso en rojo. El elemento LCP de la parte inferior, una miniatura con su HTML, muestra qué elemento midió Lighthouse en la pantalla de un móvil. «Unscored» significa que el aviso no aporta puntos por sí mismo, pero el LCP cuenta una cuarta parte de la puntuación de Performance, y Google posiciona según lo que reciben los visitantes reales. El aviso solo aparece cuando el elemento LCP es una imagen: un <img>, un fondo CSS o el poster de un vídeo.

¿Por qué una imagen del LCP tardía ralentiza la página?

En un móvil, el visitante ve el titular y el texto alrededor de un bloque vacío donde va la foto grande, durante un segundo o más.

Mientras se descarga el HTML, el preload scanner de Chrome lo lee por anticipado y pide cada imagen presente en el src o srcset de un <img> sin loading="lazy": lo antes que puede empezar una foto. Cualquier otra foto empieza más tarde: en una hoja de estilos espera a ese archivo y al layout; en un atributo style o con loading="lazy" espera al layout, que antes necesita cada hoja de estilos render blocking; un slider o un script de lazy loading tiene que descargarse y ejecutarse antes de pedir la foto.

Esa espera, el resource load delay, suele durar más que la descarga: en la mediana de los sitios con un mal LCP, la imagen espera 1.290 ms y luego se descarga en 350 ms (web.dev).

En la página de inicio de un hotel que monté como un sitio WordPress con un page builder, coloqué la misma foto de siete formas distintas y cargué cada una en un móvil con throttling:

Medianas de cinco cargas, en segundos, en Slow 4G con una CPU 4x más lenta. El HTML llegó a los 0,58 s en cada ocasión.

Todas las versiones cargaron la misma foto de 63 kB, salvo la del atributo style, que no puede cambiar al archivo más pequeño para móvil. El momento en que empezó la petición marcó la diferencia: la foto en el HTML se pidió nada más llegar el HTML; las demás esperaron al primer paint a los 1,7 s o a los scripts a los 2,4 s.

La página del hotel a los 2,5 segundos de carga en el mismo móvil con throttling.

fetchpriority="high" le dice a Chrome desde el primer instante que esta imagen importa, por lo que recibe más recursos de la conexión. En una página sobrecargada, donde la foto compite con decenas de scripts y hojas de estilo, eso puede acelerar el LCP: Google midió una bajada de 2,6 s a 1,9 s en Google Flights. Solo ayuda a una foto que el navegador ya ha encontrado: una foto en una hoja de estilos o en un script necesita primero el cambio en el HTML.

¿Por qué fetchpriority=high sigue en rojo si la imagen ya lo tiene?

El check analiza la petición que cargó la imagen del LCP. Busca el nombre de archivo de la foto en el código fuente de la página, sin iniciar sesión. Las causas habituales (fixes más abajo):

• Un preload que no escribiste tú. Un tema, el hosting o una CDN pueden enviar un preload para la foto en una cabecera Link o mediante 103 Early Hints; un plugin de caché o Next.js añade un <link rel="preload"> en el head. Para comprobar la cabecera, abre el panel Network en DevTools, haz clic en la primera petición (la propia página) y lee sus Headers.
• Un plugin de lazy loading reescribió la imagen. Cuando el check de descubribilidad también está en rojo, busca data-src o data-lazy-src en la foto: un plugin movió la URL ahí y un script pide la foto más tarde.
• WordPress asignó el atributo a otra imagen. WordPress añade fetchpriority="high" a la primera imagen grande en la primera pantalla (50.000 píxeles o más). Un logo subido a doble tamaño, por ejemplo de 600 por 200 píxeles, aparece primero y se lo queda.
• Lighthouse midió una imagen distinta. El elemento LCP al final del aviso muestra cuál fue. En un móvil puede ser un hero móvil independiente, con la foto de escritorio oculta por CSS y el atributo puesto en esa foto de escritorio.

La página del hotel con un script de lazy loading: dos checks en rojo. Lighthouse 13.6 con throttling de DevTools.

¿Cuánto tiempo esperan los visitantes la imagen del LCP?

Los field data muestran cuánto esperan los visitantes reales. En CoreDash, abre LCP Breakdown para móvil y selecciona LCP Priority en More dimensions: cada fila representa una forma en que se cargó la imagen del LCP, con su LCP p75 dividido en partes. La parte verde es el load delay, la espera entre la llegada del HTML y el momento en que la imagen empieza a descargarse. Agrupa por URL para localizar la plantilla donde esa espera es larga.

CoreDash en móvil, p75: compara la parte verde de cada fila de LCP Priority.

¿Cómo ver en DevTools con qué retraso empezó la imagen?

Graba una traza de la página en el panel Performance de Chrome DevTools y abre LCP request discovery en la barra lateral de Insights. En la página de prueba del hotel, con la foto como fondo en la hoja de estilos del page builder, el insight muestra cuánto tiempo después del primer byte del HTML —su «earliest start point»— empezó la petición de la foto. La barra rayada en la pista Network marca esa espera.

La petición de la foto empieza después de las hojas de estilo. Chrome DevTools, panel Performance, móvil con throttling.

En el panel Network, la columna Initiator junto a la foto indica el archivo que la pidió: una hoja de estilos, el script de un slider o el HTML si empezó a tiempo.

¿Cómo corregir LCP request discovery?

Busca el nombre de archivo de la foto en el código fuente de la página. En el src o srcset de un <img>, el navegador la encuentra pronto; en data-src, en una hoja de estilos o en ninguna parte, eso es lo que hay que cambiar. El objetivo siempre: la foto como un <img> en el HTML, sin loading="lazy", con fetchpriority="high", en esa única imagen. Añade fetchpriority="high" a un preload que no hayas escrito tú, o desactívalo. Sustituye un hero móvil independiente por una sola foto para ambas pantallas, o un <picture> con un <source> para el archivo del móvil y fetchpriority="high" en su <img>.

WordPress y plugins de lazy loading

WordPress excluye las primeras imágenes del lazy loading y le da fetchpriority="high" a la primera imagen grande. Si el aviso sigue en rojo, suele ser porque un plugin anula esto:

• WP Rocket: Optimize Critical Images, activo por defecto, detecta la imagen del LCP a partir de visitas reales, genera un preload con fetchpriority="high" y la excluye de LazyLoad. Vuelve a probar una vez regenerada la caché.
• Perfmatters: configura Exclude Leading Images y Preload Critical Images con el número de imágenes de la primera pantalla en un móvil, normalmente una.
• LiteSpeed Cache: añade el nombre de archivo de la foto a Lazy Load Image Excludes, o activa Viewport Images.
• FlyingPress: comprueba que la foto tenga loading="eager" y un preload; si no, exclúyela del lazy loading.

Sube el logo al tamaño con el que se muestra, para que el atributo vaya a la foto. Mantén un solo sistema de lazy loading, o la foto seguirá en lazy loading tras haberla excluido en uno. En el bloque Cover, Fixed background convierte la foto en un fondo dentro de un atributo style: desactívalo y la foto volverá a ser un <img>. Mi plugin WP Core Web Vitals detecta la imagen del LCP por tamaño de pantalla a partir de las visitas y la carga primero, con prioridad alta.

Elementor y otros page builders

Una foto definida como fondo de un Container o Section de Elementor acaba en el CSS de Elementor, así que el navegador solo la encuentra después de ese CSS y del layout. Usa un widget Image para la foto del hero (un hero de Elementor con una imagen); Optimized Image Loading (Settings, Performance) se encargará de gestionarla igual que WordPress. Lazy Load Background Images, activo por defecto, puede frenar un hero de fondo situado debajo de una barra de avisos. En otros builders, usa también un elemento de imagen para la primera foto.

Sliders

La primera slide tiene que ser un <img> en el HTML, sin loading="lazy", con fetchpriority="high"; las demás slides llevan loading="lazy" y fetchpriority="low". Un slider que monta sus slides con JavaScript solo inicia la primera después de ejecutar ese script: usa uno que imprima la primera slide en el HTML, o muestra una sola foto en móviles. En Image Carousel de Elementor, la opción Lazyload pasa la URL de cada slide a data-src: desactívala.

Shopify

Dawn, Horizon y los temas basados en ellos asignan fetchpriority="high" a la imagen de la primera sección de una plantilla y la cargan de inmediato; por tanto, coloca el banner o el slideshow como primera sección. En una página de producto de Dawn, la foto principal no tiene fetchpriority: en snippets/product-thumbnail.liquid, añade fetchpriority: 'high' al image_tag cuando lazy_load sea false (la primera foto). Una actualización del tema puede sobrescribir este archivo: comprueba el atributo después. Un hero que una app monta con JavaScript empezará tarde haga lo que haga el tema: recurre a una sección del tema.

En otros temas, busca en el archivo de la sección loading: 'lazy' o una clase lazyload con data-src, y define la prioridad según la posición de la sección:

{%- liquid
  assign fetch_priority = 'auto'
  if section.index == 1
    assign fetch_priority = 'high'
  endif
-%}
{{ section.settings.image | image_url: width: 1600 | image_tag: widths: '750, 1100, 1600', sizes: '100vw', fetchpriority: fetch_priority }}

Sin un parámetro loading, image_tag aplica lazy loading a las imágenes a partir de la cuarta sección.

Imágenes de fondo CSS

Sin una opción de imagen en el tema o builder, esto requiere a un desarrollador. Convierte primero el fondo en un <img>: el navegador lo encuentra en el HTML y srcset permite que cada pantalla elija su propio archivo. object-fit hace que rellene el espacio tal como lo hacía el fondo:

<section class="hero">
  <img class="hero-img" src="/wp-content/uploads/2026/10/terrace-1024.jpg"
    srcset="/wp-content/uploads/2026/10/terrace-768.jpg 768w, /wp-content/uploads/2026/10/terrace-1024.jpg 1024w, /wp-content/uploads/2026/10/terrace-1600.jpg 1600w"
    sizes="100vw" width="1600" height="1067" alt="Terrace above the sea" fetchpriority="high">
</section>

.hero { position: relative; }
.hero-img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

Si tiene que quedarse como fondo, haz preload del archivo que elija el CSS para cada tamaño de pantalla, con las media queries del CSS y fetchpriority="high"; un preload para otro archivo descarga la foto dos veces. Añádelo solo a la plantilla de esa página. Para un CSS que cambia al archivo de 768 px por debajo de 768 px:

<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-768.jpg" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-1600.jpg" media="(min-width: 768px)" fetchpriority="high">

Next.js, Astro y React

next/image aplica lazy loading por defecto. Desde Next.js 15, priority (preload en la versión 16) hace que la imagen sea eager y genera un preload sin fetchpriority, por lo que el check sigue en rojo. Configura ambos tú mismo, sin priority:

<Image src={hero} alt="Terrace above the sea" sizes="100vw" loading="eager" fetchPriority="high" />

En Astro 5.10 y versiones posteriores, la prop priority en <Image> configura ambos. Un hero que React renderiza en el navegador solo existe después de que se ejecute el JavaScript: renderízalo en el servidor o prerenderiza la página, para que el <img> esté en el HTML.

Un hero que no puedes cambiar

Un test A/B que cambia la foto o un widget que monta el hero con JavaScript hacen que empiece tarde. Si la URL de la foto se mantiene igual, un preload con fetchpriority="high" en la propia plantilla hace que empiece pronto. En un servidor lento, 103 Early Hints puede iniciar una foto que usa el mismo archivo en todas las pantallas antes de que llegue el HTML. Ambas opciones requieren a un desarrollador.

¿Empieza ahora la imagen del LCP junto con el HTML?

Pasa de nuevo Lighthouse: tres checks en verde y la foto como elemento LCP. En DevTools la petición de la foto empieza justo después del HTML. ¿Pasa los checks y el LCP sigue lento? Revisa las demás partes del LCP: un servidor lento (time to first byte), una foto que tarda en descargarse (load duration) o bien hojas de estilo y scripts que retrasan el render (render delay). Para los visitantes reales, vigila el load delay en móviles en CoreDash; Search Console tarda hasta 28 días.

Una Core Web Vitals power hour está pensada para la foto a la que esta página no llega: una colocada por un page builder, slider o app que no tiene ajustes para ella, o una que pasa los tres checks mientras el LCP en móviles sigue lento. La seguimos a través de una traza de tu página, desde el HTML hasta la pantalla, y descubrimos qué la está frenando.