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

O que diz o LCP request discovery sobre a imagem de 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". Verifica se a imagem de LCP — a foto grande pela qual os visitantes esperam — pode ser descoberta a partir do HTML: se o browser podia começar a descarregá-la no momento em que o HTML chegou, com prioridade alta. A solução: a foto como <img> no HTML, sem loading="lazy", com fetchpriority="high".

Só quer a solução rápida? Salte 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". Por baixo estão três verificações, cada uma a verde ou a vermelho.

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

• fetchpriority=high should be applied: o browser pediu a imagem de LCP sem fetchpriority="high". Quando a foto veio através de um preload, a verificação diz "fetchpriority=high should be applied to the image preload request": o preload também precisa dele. Quando passa no teste, diz "fetchpriority=high applied".
• Request is discoverable in initial document: o URL da foto está no próprio HTML, num <img> ou num preload, onde o preload scanner (a parte do browser que lê o HTML antecipadamente) o encontra. Uma imagem de fundo numa folha de estilos, um slider que constrói os slides com JavaScript ou um script de lazy loading que moveu o URL para data-src deixam esta verificação a vermelho.
• LCP resources shouldn’t use loading=lazy: a foto tem loading="lazy", pelo que o browser só a pede quando o layout mostrar que está no ecrã.

Basta uma verificação a vermelho para o aviso ficar vermelho. O elemento LCP no fundo, uma miniatura com o respetivo HTML, mostra o elemento que o Lighthouse mediu no ecrã de um telemóvel. Unscored significa que o aviso não acrescenta pontos por si só, mas o LCP vale um quarto da pontuação de Performance, e o Google baseia o ranking no que os visitantes reais obtêm. O aviso só surge quando o elemento LCP é uma imagem: um <img>, um fundo em CSS ou um poster de vídeo.

Porque é que uma imagem de LCP tardia torna a página lenta?

Num telemóvel, o visitante vê o título e o texto em redor de um bloco vazio onde fica a foto grande, durante um segundo ou mais.

Enquanto o HTML é descarregado, o preload scanner do Chrome lê o documento antecipadamente e pede todas as imagens no src ou srcset de um <img> sem loading="lazy": o momento mais cedo em que uma foto pode arrancar. Qualquer outra foto arranca mais tarde: numa folha de estilos, espera por esse ficheiro e pelo layout; num atributo style ou com loading="lazy", espera pelo layout, que precisa primeiro de cada folha de estilos render-blocking; um slider ou script de lazy loading tem de ser descarregado e executado antes de pedir a foto.

Essa espera, o resource load delay, costuma demorar mais do que o download: no site mediano com um LCP fraco, a imagem espera 1290 ms e depois descarrega em 350 ms (web.dev).

Numa página inicial de hotel que criei à semelhança de um site WordPress com page builder, coloquei a mesma foto de sete formas e carreguei cada uma num telemóvel com throttling:

Medianas de cinco carregamentos, em segundos, em Slow 4G com CPU 4x mais lento. O HTML chegou sempre aos 0,58 s.

Todas as versões carregaram a mesma foto de 63 kB, exceto o atributo style, que não consegue alternar para o ficheiro mais pequeno de telemóvel. O momento de início do pedido fez a diferença: a foto no HTML foi pedida assim que o HTML chegou; as outras esperaram pelo first paint aos 1,7 s ou pelos scripts aos 2,4 s.

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

O fetchpriority="high" indica ao Chrome logo no primeiro momento que esta imagem é importante, garantindo-lhe mais recursos da ligação. Numa página pesada, onde a foto compete com dezenas de scripts e folhas de estilos, isso pode acelerar o LCP: a Google mediu uma descida de 2,6 s para 1,9 s no Google Flights. Só ajuda uma foto que o browser já tenha encontrado: uma foto numa folha de estilos ou num script precisa primeiro da alteração no HTML.

Porque é que o fetchpriority=high continua a vermelho quando a imagem o tem?

A verificação analisa o pedido que carregou a imagem de LCP. Procure o nome do ficheiro da foto no código-fonte da página, sem sessão iniciada. As causas habituais (soluções abaixo):

• Um preload que não escreveu. Um tema, o alojamento ou uma CDN podem enviar um preload para a foto num cabeçalho Link ou em 103 Early Hints; um plugin de cache ou o Next.js adiciona um <link rel="preload"> ao head. Para verificar um cabeçalho, abra o painel Network nas DevTools, clique no primeiro pedido (a própria página) e consulte os Headers.
• Um plugin de lazy loading reescreveu a imagem. Se a verificação de descoberta também estiver a vermelho, procure data-src ou data-lazy-src na foto: um plugin moveu o URL para aí, e um script pede a foto mais tarde.
• O WordPress atribuiu o atributo a outra imagem. O WordPress adiciona fetchpriority="high" à primeira imagem grande no primeiro ecrã (50 000 píxeis ou mais). Um logótipo carregado no dobro do tamanho, por exemplo 600 por 200 píxeis, surge primeiro e fica com ele.
• O Lighthouse mediu uma imagem diferente. O elemento LCP no fundo do aviso mostra qual foi. Num telemóvel, pode ser um hero de mobile separado, com a foto de desktop oculta por CSS e o atributo nessa foto de desktop.

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

Quanto tempo esperam os visitantes pela imagem de LCP?

Os field data mostram quanto tempo os visitantes reais esperam. No CoreDash, abra o LCP Breakdown em mobile e escolha LCP Priority em More dimensions: cada linha representa uma forma como a imagem de LCP foi carregada, com o respetivo LCP p75 dividido em partes. A parte verde é o load delay, a 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 em mobile, p75: compare a parte verde de cada linha de LCP Priority.

Como ver nas DevTools o atraso no arranque da imagem?

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

O pedido da foto arranca depois das folhas de estilos. Chrome DevTools, painel Performance, telemóvel com throttling.

No painel Network, a coluna Initiator junto à foto indica o ficheiro que a pediu: uma folha de estilos, um script de slider ou o HTML, quando arrancou a tempo.

Como corrigir o LCP request discovery?

Procure o nome do ficheiro da foto no código-fonte da página. Num src ou srcset de um <img>, o browser encontra-a logo; se estiver em data-src, numa folha de estilos ou em lado nenhum, é isso que tem de mudar. O objetivo em qualquer caso: a foto como <img> no HTML, sem loading="lazy", com fetchpriority="high", nessa imagem específica. Adicione fetchpriority="high" a um preload que não tenha escrito, ou desative-o. Substitua um hero de mobile separado por uma única foto para ambos os ecrãs, ou por um <picture> com um <source> para o ficheiro de telemóvel e fetchpriority="high" no respetivo <img>.

WordPress e plugins de lazy loading

O WordPress mantém as primeiras imagens fora do lazy loading e atribui fetchpriority="high" à primeira imagem grande. Quando o aviso continua a vermelho, a causa costuma ser um plugin a sobrepor-se a isto:

• WP Rocket: a opção Optimize Critical Images, ativa por predefinição, aprende qual é a imagem de LCP a partir de visitas reais, faz o preload com fetchpriority="high" e mantém-na fora do LazyLoad. Teste novamente após reconstruir a cache.
• Perfmatters: defina Exclude Leading Images e Preload Critical Images para o número de imagens no primeiro ecrã num telemóvel, frequentemente uma.
• LiteSpeed Cache: adicione o nome do ficheiro da foto a Lazy Load Image Excludes, ou ative Viewport Images.
• FlyingPress: confirme se a foto tem loading="eager" e um preload; se não tiver, exclua-a do lazy loading.

Carregue o logótipo no tamanho em que é apresentado, para que o atributo vá para a foto. Mantenha apenas uma solução de lazy loading, senão a foto continuará em lazy loading depois de a ter excluído numa delas. No bloco Cover, a opção Fixed background transforma a foto num fundo num atributo style: desative-a e a foto volta a ser um <img>. O meu plugin WP Core Web Vitals aprende a imagem de LCP por tamanho de ecrã a partir dos visitantes e carrega-a primeiro, com prioridade alta.

Elementor e outros page builders

Uma foto definida como fundo de um Container ou Section do Elementor vai parar ao CSS do Elementor; por isso, o browser só a encontra depois desse CSS e do layout. Use um widget Image para a foto de hero (um hero no Elementor com uma imagem); a opção Optimized Image Loading (Settings, Performance) trata dela como o WordPress. A opção Lazy Load Background Images, ativa por predefinição, pode atrasar um hero em fundo que fique por baixo de uma barra de aviso. Também noutros builders: use um elemento de imagem para a primeira foto.

Sliders

O primeiro slide tem de ser um <img> no HTML, sem loading="lazy", com fetchpriority="high"; os restantes slides recebem loading="lazy" e fetchpriority="low". Um slider que constrói os slides com JavaScript só inicia o primeiro slide depois da execução desse script: use um slider que imprima o primeiro slide no HTML, ou mostre uma única foto em telemóveis. No Image Carousel do Elementor, a opção Lazyload coloca o URL de todos os slides em data-src: desative-a.

Shopify

O Dawn, o Horizon e os temas baseados neles atribuem fetchpriority="high" à imagem da primeira secção do template e carregam-na de imediato; por isso, torne o banner ou slideshow a primeira secção. Numa página de produto do Dawn, a foto principal não tem fetchpriority: em snippets/product-thumbnail.liquid, adicione fetchpriority: 'high' à image_tag quando lazy_load for false (a primeira foto). Uma atualização do tema pode substituir este ficheiro: confirme o atributo a seguir. Um hero que uma app construa com JavaScript arranca sempre tarde, independentemente do que o tema faça: use uma secção do tema.

Noutros temas, procure loading: 'lazy' ou uma classe lazyload com data-src no ficheiro da secção, e defina a prioridade com base na posição da secçã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 a imagens a partir da quarta secção.

Imagens de fundo em CSS

Sem uma opção de imagem no seu tema ou builder, isto exige um developer. Comece por converter o fundo num <img>: o browser encontra-o logo no HTML e o srcset permite que cada ecrã escolha o seu ficheiro. O object-fit faz com que preencha o espaço tal como o fundo 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 tiver mesmo de continuar como fundo, faça o preload do ficheiro que o CSS escolhe por tamanho de ecrã, com as media queries do CSS e fetchpriority="high"; um preload para outro ficheiro descarrega a foto duas vezes. Adicione-o apenas ao template dessa página. Para um CSS que muda para o ficheiro 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 predefinição. Desde o Next.js 15, a prop priority (preload no 16) torna o carregamento da imagem eager e faz o preload sem fetchpriority, pelo que a verificação continua a vermelho. Defina ambos 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 renderize no browser só existe após a execução do JavaScript: renderize-o no servidor ou pré-renderize a página, para que o <img> conste no HTML.

Um hero que não pode alterar

Um teste A/B que troca a foto ou um widget que constrói o hero com JavaScript atrasam o arranque da imagem. Se o URL da foto não mudar, um preload com fetchpriority="high" no seu próprio template antecipa o pedido. Num servidor lento, o 103 Early Hints consegue iniciar uma foto que use o mesmo ficheiro em todos os ecrãs antes de o HTML chegar. Ambos exigem um developer.

A imagem de LCP já arranca com o HTML?

Execute o Lighthouse novamente: três verificações a verde e a foto identificada como elemento LCP. Nas DevTools, o pedido da foto arranca logo a seguir ao HTML. Passou nos testes e o LCP continua lento? Analise as outras partes do LCP: um servidor lento (time to first byte), uma foto que demora a descarregar (load duration) ou folhas de estilos e scripts que atrasam o paint (render delay). Para visitantes reais, acompanhe o load delay em telemóveis no CoreDash; a Search Console demora até 28 dias.

A Core Web Vitals power hour serve para a foto que esta página não consegue resolver: uma foto colocada por um page builder, slider ou app sem qualquer configuração disponível, ou uma que passa nas três verificações enquanto o LCP em telemóveis continua lento. Acompanhamo-la através de um trace da sua própria página, desde o HTML até ao ecrã, e descobrimos o que a está a atrasar.