LCP request discovery no Lighthouse: verificações e a correção

O que o LCP request discovery diz sobre a imagem do LCP?

O LCP request discovery é o insight do Lighthouse 13 que substituiu "Preload Largest Contentful Paint image" e "Largest Contentful Paint image was lazily loaded". Ele verifica se a imagem do LCP, a foto principal que os visitantes esperam, pode ser descoberta a partir do HTML: se o navegador pôde começar a baixá-la assim que o HTML chegou, com prioridade alta. A correção: a foto como um <img> no HTML, sem loading="lazy", com fetchpriority="high".

Quer apenas a solução rápida? Pule para WordPress, page builders, Shopify ou Next.js.

O que significam as três verificações do LCP request discovery?

No Lighthouse 13 e no PageSpeed Insights, o aviso diz: "Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading". Abaixo dele há três verificações, cada uma verde ou vermelha.

O aviso para a página inicial de um hotel cuja foto principal usa loading="lazy". Lighthouse 13.6 com throttling do DevTools.

• fetchpriority=high should be applied: o navegador solicitou a imagem do LCP sem fetchpriority="high". Quando a foto vem por meio de um preload, a verificação exibe "fetchpriority=high should be applied to the image preload request": o preload também precisa dele. Quando o teste passa, ela exibe "fetchpriority=high applied".
• Request is discoverable in initial document: a URL da foto está no próprio HTML, em um <img> ou preload, onde o preload scanner (a parte do navegador que faz a leitura antecipada do HTML) a encontra. Uma imagem de fundo no CSS, um slider que monta os slides via JavaScript ou um script de lazy loading que moveu a URL para data-src deixam essa verificação vermelha.
• LCP resources shouldn’t use loading=lazy: a foto usa loading="lazy", então o navegador só faz a requisição quando o layout confirma que ela está na tela.

Basta uma verificação vermelha para o aviso ficar vermelho. O elemento do LCP na parte inferior, uma miniatura com o HTML, mostra qual elemento o Lighthouse mediu na tela do celular. Unscored significa que o aviso não altera a pontuação por si só, mas o LCP responde por um quarto da nota de Performance, e o Google ranqueia pelo que os visitantes reais experimentam. O aviso só aparece quando o elemento do LCP é uma imagem: um <img>, um background CSS ou o poster de um vídeo.

Por que uma imagem do LCP atrasada deixa a página lenta?

No celular, o visitante vê o título e o texto ao redor de um bloco vazio onde fica a foto principal, por um segundo ou mais.

Enquanto o HTML baixa, o preload scanner do Chrome lê o documento com antecedência e solicita toda imagem em src ou srcset de <img> sem loading="lazy": o momento mais cedo em que uma foto pode começar. Qualquer outra foto começa mais tarde: na folha de estilo, ela espera o arquivo e o layout; em um atributo style ou com loading="lazy", ela espera o layout, que precisa de cada stylesheet render blocking antes; um slider ou script de lazy loading precisa baixar e rodar antes de pedir a foto.

Essa espera, o resource load delay, costuma demorar mais do que o download: na mediana dos sites com LCP ruim, a imagem espera 1.290 ms e depois baixa em 350 ms (web.dev).

Na página inicial de um hotel que montei como um site WordPress com page builder, coloquei a mesma foto na página de sete formas e carreguei cada uma em um celular com throttling:

Medianas de cinco carregamentos, em segundos, em Slow 4G com CPU 4x mais lenta. O HTML chegou a 0,58 s em todas as vezes.

Todas as versões carregaram a mesma foto de 63 kB, com exceção do atributo style, que não consegue alternar para o arquivo menor de celular. O início da requisição fez toda a diferença: a foto no HTML foi solicitada assim que o HTML chegou; as outras esperaram o first paint aos 1,7 s ou os scripts aos 2,4 s.

A página do hotel aos 2,5 segundos de carregamento no mesmo celular com throttling.

O fetchpriority="high" diz ao Chrome desde o primeiro instante que essa imagem importa, priorizando a conexão para ela. Em uma página pesada, onde a foto concorre com dezenas de scripts e stylesheets, isso pode acelerar o LCP: o Google registrou uma queda de 2,6 s para 1,9 s no Google Flights. Mas ele só ajuda imagens que o navegador já encontrou: uma foto em um stylesheet ou script precisa primeiro da alteração no HTML.

Por que o fetchpriority=high continua vermelho se a imagem já tem o atributo?

A verificação analisa a requisição que carregou a imagem do LCP. Faça uma busca pelo nome do arquivo da foto no código-fonte da página, sem estar logado. As causas mais comuns (soluções abaixo):

• Um preload que você não configurou. Um tema, hospedagem ou CDN pode enviar um preload da foto em um cabeçalho Link ou no 103 Early Hints; um plugin de cache ou o Next.js adiciona um <link rel="preload"> no head. Para checar o cabeçalho, abra o painel Network no DevTools, clique na primeira requisição (a própria página) e leia os Headers.
• Um plugin de lazy loading reescreveu a imagem. Se a verificação de descoberta também estiver vermelha, procure por data-src ou data-lazy-src na foto: um plugin moveu a URL para lá, e um script requisita a foto mais tarde.
• O WordPress aplicou o atributo em outra imagem. O WordPress adiciona fetchpriority="high" à primeira imagem grande na primeira tela (50.000 pixels ou mais). Um logo enviado com o dobro do tamanho, digamos 600 por 200 pixels, aparece antes e fica com o atributo.
• O Lighthouse mediu outra imagem. O elemento do LCP na parte inferior do aviso mostra qual foi medido. No celular, pode ser um hero separado para mobile, com a foto de desktop oculta por CSS e o atributo aplicado nessa foto de desktop.

A página do hotel com script de lazy loading: duas verificações vermelhas. Lighthouse 13.6 com throttling do DevTools.

Quanto tempo os visitantes esperam pela imagem do LCP?

Os field data mostram quanto tempo os visitantes reais esperam. No CoreDash, abra o LCP Breakdown para celular e selecione LCP Priority em More dimensions: cada linha representa uma forma como a imagem do LCP foi carregada, com o LCP p75 dividido em partes. A parte verde é o load delay, o tempo de espera entre a chegada do HTML e o início do download da imagem. Agrupe por URL para encontrar o template onde essa espera é longa.

CoreDash no celular, p75: compare a parte verde de cada linha de LCP Priority.

Como ver no DevTools o atraso no início da imagem?

Grave um trace da página no painel Performance do Chrome DevTools e abra o LCP request discovery na barra lateral de Insights. Na minha página de teste do hotel, com a foto como background na folha de estilo do page builder, o insight mostra quanto tempo após o primeiro byte do HTML — seu "earliest start point" — a requisição da foto começou. A barra listrada na trilha Network marca essa espera.

A requisição da foto começa depois dos stylesheets. Chrome DevTools, painel Performance, celular com throttling.

No painel Network, a coluna Initiator ao lado da foto mostra o arquivo que fez a requisição: um stylesheet, um script de slider ou o HTML, quando começou no tempo certo.

Como corrigir o LCP request discovery?

Localize o nome do arquivo da foto no código-fonte da página. Em um src ou srcset de <img>, o navegador a encontra cedo; em data-src, em uma folha de estilo ou em lugar nenhum, é isso que precisa mudar. O objetivo em qualquer caso: a foto como um <img> no HTML, sem loading="lazy", com fetchpriority="high", nessa imagem específica. Adicione fetchpriority="high" a um preload que você não criou ou desative-o. Substitua um hero mobile separado por uma única foto para as duas telas, ou use um <picture> com <source> para o arquivo de celular e fetchpriority="high" no <img>.

WordPress e plugins de lazy loading

O WordPress mantém as primeiras imagens fora do lazy loading e aplica fetchpriority="high" na primeira imagem grande. Se o aviso continuar vermelho, geralmente algum plugin está sobrescrevendo isso:

• WP Rocket: Optimize Critical Images, ativo por padrão, identifica a imagem do LCP a partir de visitas reais, faz o preload com fetchpriority="high" e a mantém fora do LazyLoad. Teste novamente após reconstruir o cache.
• Perfmatters: defina Exclude Leading Images e Preload Critical Images com o número de imagens na primeira tela do celular, geralmente uma.
• LiteSpeed Cache: adicione o nome do arquivo da foto em Lazy Load Image Excludes ou ative Viewport Images.
• FlyingPress: verifique se a foto tem loading="eager" e um preload; caso contrário, exclua a imagem do lazy loading.

Faça o upload do logo no tamanho exato em que ele aparece, para que o atributo vá para a foto. Mantenha apenas um sistema de lazy loading, senão a foto continuará em lazy loading mesmo após ser excluída em um deles. No bloco Cover, Fixed background transforma a foto em um background dentro de um atributo style: desative essa opção para que a foto volte a ser um <img>. Meu plugin WP Core Web Vitals identifica a imagem do LCP por tamanho de tela a partir dos visitantes e a carrega primeiro, com alta prioridade.

Elementor e outros page builders

Uma foto definida como background de um Container ou Section do Elementor vai parar no CSS do Elementor, então o navegador só a encontra depois desse CSS e do layout. Use um widget Image para a foto do hero (um hero do Elementor com imagem); a opção Optimized Image Loading (Settings, Performance) cuidará dela como o WordPress faz. Lazy Load Background Images, ativa por padrão, pode atrasar um hero em background que fica sob uma barra de avisos. Em outros builders também, use um elemento de imagem para a primeira foto.

Sliders

O primeiro slide precisa ser um <img> no HTML, sem loading="lazy", com fetchpriority="high"; os outros slides recebem loading="lazy" e fetchpriority="low". Um slider que monta os slides com JavaScript só inicia o primeiro slide depois que esse script roda: use um slider que imprima o primeiro slide no HTML, ou exiba uma única foto em celulares. No Image Carousel do Elementor, a opção Lazyload joga a URL de cada slide no data-src: desative-a.

Shopify

Dawn, Horizon e os temas baseados neles aplicam fetchpriority="high" à imagem da primeira seção do template e a carregam imediatamente. Por isso, coloque o banner ou slideshow como a primeira seção. Na página de produto do Dawn, a foto principal não tem fetchpriority: em snippets/product-thumbnail.liquid, adicione fetchpriority: 'high' na image_tag quando lazy_load for false (a primeira foto). Uma atualização de tema pode sobrescrever esse arquivo: verifique o atributo depois. Um hero montado por app com JavaScript começa tarde qualquer que seja o tema: use uma seção nativa do tema.

Em outros temas, procure no arquivo da seção por loading: 'lazy' ou por uma classe lazyload com data-src, e vincule a prioridade à posição da seção:

{%- 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 }}

Sem o parâmetro loading, a image_tag aplica lazy loading nas imagens a partir da quarta seção.

Imagens de background em CSS

Sem uma opção de imagem no tema ou builder, isso exige um desenvolvedor. Primeiro, transforme o background em um <img>: o navegador passa a encontrá-lo no HTML, e o srcset permite que cada tela escolha o próprio arquivo. O object-fit faz a imagem preencher o espaço exatamente como o background fazia:

<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; }

Se for obrigatório mantê-la como background, faça o preload do arquivo que o CSS escolhe por tamanho de tela, com as mesmas media queries do CSS e fetchpriority="high"; o preload de outro arquivo baixa a foto duas vezes. Adicione isso apenas ao template daquela página. Para um CSS que muda para o arquivo de 768 px abaixo 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 e React

O next/image aplica lazy loading por padrão. Desde o Next.js 15, o atributo priority (preload no 16) torna a imagem eager e faz o preload sem fetchpriority, mantendo a verificação vermelha. Defina os dois manualmente, sem priority:

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

No Astro 5.10 e versões posteriores, a prop priority no <Image> define ambos. Um hero que o React renderiza no navegador só existe depois que o JavaScript roda: renderize no servidor ou faça o pré-render da página para que o <img> esteja no HTML.

Um hero que você não pode alterar

Um teste A/B que troca a foto ou um widget que monta o hero com JavaScript iniciam o carregamento tarde. Se a URL da foto não mudar, um preload com fetchpriority="high" no template antecipa o início. Em um servidor lento, o 103 Early Hints pode iniciar uma foto que usa o mesmo arquivo em qualquer tela antes de o HTML chegar. Ambas as soluções exigem um desenvolvedor.

A imagem do LCP agora começa junto com o HTML?

Execute o Lighthouse novamente: três verificações verdes e a foto como o elemento do LCP. No DevTools, a requisição da foto começa logo após o HTML. Passou e o LCP continua lento? Avalie as outras partes do LCP: servidor lento (time to first byte), foto que demora para baixar (load duration) ou stylesheets e scripts que atrasam a renderização (render delay). Para visitantes reais, acompanhe o load delay em celulares no CoreDash; o Search Console leva até 28 dias.

A Core Web Vitals power hour é indicada para a foto que esta página não consegue resolver: aquela inserida por page builder, slider ou app sem essa configuração, ou aquela que passa nas três verificações enquanto o LCP em celulares continua lento. Rastreamos a foto em um trace da página, do HTML até a tela, e encontramos o que está segurando o carregamento.