Uma hero pode estar comprimida, usar WebP e ainda aparecer tarde. O problema nem sempre está no peso do arquivo. Às vezes o navegador só descobre a imagem depois de baixar CSS, executar JavaScript ou montar um componente.

Largest Contentful Paint, ou LCP, mede quando o maior bloco de imagem ou texto visível na primeira tela termina de renderizar. Para melhorar esse tempo, você precisa localizar o elemento real, separar as etapas do atraso e alterar o ponto que domina a medição.

Este guia trata da imagem hero, um candidato frequente ao LCP em landing pages. Se o maior elemento da sua página for um título, uma fonte web ou um pôster de vídeo, o diagnóstico muda.

Confirme qual elemento define o LCP

Não presuma que a imagem mais larga do código é o LCP. O elemento pode mudar por largura de tela, conteúdo, estado de consentimento ou teste de campanha.

Use pelo menos dois cenários:

  • celular, com rede e CPU limitadas;
  • desktop, em uma janela representativa do tráfego.

O PageSpeed Insights ajuda a comparar dados de laboratório e de campo. No Chrome DevTools, grave um trace no painel Performance e abra o evento de LCP para ver o elemento associado. A documentação do web.dev sobre otimização de LCP usa 2,5 segundos ou menos no 75º percentil como faixa boa, separada entre mobile e desktop.

Registre a linha de base antes de editar:

URL e versão publicada:
dispositivo e largura:
origem do dado: campo ou laboratório
elemento de LCP:
URL do recurso:
tempo até o primeiro byte:
início e fim do download:
momento da renderização:

O guia de Core Web Vitals para sites criados por IA mostra como não misturar uma execução de laboratório com a distribuição real das visitas.

Separe as quatro partes do atraso

Uma imagem de LCP passa por quatro intervalos:

  1. tempo até o primeiro byte do documento;
  2. atraso até o navegador descobrir e iniciar o recurso;
  3. duração do download;
  4. atraso entre o fim do download e a renderização do elemento.

Essa divisão evita correções por hábito. Converter uma imagem para AVIF pode reduzir o terceiro intervalo, mas não resolve um recurso descoberto tarde. Adicionar fetchpriority não corrige um servidor que demora para entregar o HTML. Preload também não ajuda se o arquivo já começa cedo e a thread principal impede a pintura.

Abra o waterfall de rede e responda:

  • a imagem começa perto do CSS principal ou só depois de outro recurso?
  • o download ocupa a maior parte do LCP?
  • a resposta termina cedo, mas a imagem aparece tarde?
  • há redirect, origem externa ou URL calculada por script no caminho?

Deixe a imagem visível no HTML inicial

O scanner de preload do navegador consegue antecipar recursos declarados no HTML enquanto o parser principal ainda trabalha. Uma imagem importante deve aparecer como src ou srcset de um elemento img no markup inicial sempre que possível.

<img
  src="/assets/hero-1280.avif"
  srcset="/assets/hero-640.avif 640w, /assets/hero-1280.avif 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Equipe revisando a página publicada"
/>

Evite esconder a URL em data-src, criar a imagem somente após a hidratação ou esperar um carrossel executar para montar o primeiro slide. Cada dependência acrescenta um degrau antes do download.

Se a imagem vem de um componente gerado por IA, inspecione o HTML produzido pela build. O código-fonte do componente não prova que o navegador recebe a URL no documento inicial.

Não aplique lazy loading ao candidato de LCP

loading="lazy" serve para mídia fora da primeira tela. Na imagem de LCP, ele atrasa de propósito a decisão de buscar o recurso.

Remova o atributo da hero e mantenha lazy loading nas imagens abaixo da dobra. Depois confira a aba Network: a imagem principal deve começar cedo, sem obrigar todas as imagens da página a disputar banda no carregamento inicial.

O artigo sobre otimização de imagens cobre formato, srcset, sizes e dimensões. O objetivo aqui é complementar esse trabalho com descoberta e prioridade.

Use fetchpriority como pista, não como garantia

O atributo fetchpriority="high" informa que aquele recurso merece prioridade maior. Ele não cria a requisição e não obriga o navegador a seguir uma ordem exata.

Use a pista no provável candidato de LCP. Não marque todas as imagens da primeira dobra como high, porque prioridades concorrentes deixam de expressar uma escolha.

A referência de Fetch Priority recomenda conferir a prioridade efetiva no DevTools e medir o efeito. Se a imagem já começa no primeiro grupo de requisições, a mudança pode ser pequena. Se ela aguardava a heurística de layout, a pista pode antecipar o início.

O guia de preload, preconnect e fetchpriority explica como cada mecanismo atua em uma parte diferente do carregamento.

Reserve preload para recursos descobertos tarde

Preload é útil quando o navegador não encontra a imagem principal cedo, por exemplo em uma background-image definida em CSS.

<link
  rel="preload"
  as="image"
  href="/assets/hero-1280.avif"
  imagesrcset="/assets/hero-640.avif 640w, /assets/hero-1280.avif 1280w"
  imagesizes="100vw"
  fetchpriority="high"
/>

O preload precisa apontar para o mesmo recurso que a página usará. Se href, imagesrcset, imagesizes, credenciais ou tipo não coincidirem, o navegador pode baixar duas versões.

Não use preload como uma lista de desejos. Cada entrada inicia uma transferência e disputa banda com CSS, fontes e scripts necessários. Adicione uma por vez, confirme a requisição no waterfall e remova a pista que não altera o caminho crítico.

Quando puder, prefira um elemento img no HTML a uma imagem de fundo para conteúdo significativo. Além da descoberta direta, ele oferece alt, dimensões intrínsecas e seleção responsiva.

Reduza o arquivo sem estragar a primeira dobra

Depois de corrigir descoberta e prioridade, reduza a duração do download:

  • exporte no tamanho próximo ao maior tamanho exibido;
  • ofereça variantes responsivas;
  • escolha AVIF ou WebP quando o suporte e a qualidade forem adequados;
  • remova metadados desnecessários;
  • ajuste qualidade comparando o conteúdo real com o tamanho do arquivo;
  • sirva o arquivo no mesmo hostname quando não houver motivo para outra origem.

Compare a imagem em telas comuns e com zoom. Gradientes, rostos, texto presente na fotografia e bordas finas revelam artefatos antes de uma composição abstrata.

Uma imagem menor não autoriza remover width e height. Preserve a proporção para não melhorar LCP criando layout shifts.

Investigue o atraso de renderização

Se o recurso termina cedo e aparece tarde, o gargalo está depois da rede.

Procure no trace:

  • CSS que ainda bloqueia a primeira renderização;
  • elemento oculto até um script adicionar classe;
  • transição de entrada que começa com opacity: 0;
  • componente inserido somente após hidratação;
  • long task ocupando a thread principal;
  • fonte de título que atrasa o bloco de texto concorrente;
  • banner ou experimento que segura a página enquanto decide uma variante.

Não esconda a hero para produzir uma entrada animada. A pessoa não se beneficia de um recurso baixado que o CSS mantém invisível. Se a animação for necessária, confirme que ela não adia o conteúdo principal nem ignora prefers-reduced-motion.

O artigo sobre JavaScript na thread principal ajuda quando a pintura espera tarefas longas.

Publique e meça a mesma rota

No Site no Ar, mantenha HTML, CSS e imagens dentro de public/. Uma alteração de referência precisa chegar junto com o novo arquivo.

  1. chame get_context no Site existente;
  2. confirme o arquivo que produz a rota medida;
  3. atualize o HTML e os assets com as file tools;
  4. mantenha public/sitemap.xml alinhado;
  5. rode os checks do projeto;
  6. use deploy para criar uma nova Version;
  7. acompanhe deploy_status até um estado terminal;
  8. abra a URL final e repita o cenário da linha de base.

O contrato de Publicação serve somente o conteúdo de public/. Arquivos salvos fora desse diretório não entram na URL pública.

Teste também o domínio próprio quando ele recebe o tráfego real. Redirect, conexão com outra origem e camadas de cache podem produzir um waterfall diferente do endereço padrão.

Prompt para uma revisão focada em LCP

Revise o LCP desta página sem publicar ainda.


URL e versão: [URL e commit]
Cenários: [mobile e desktop]
Evidência: [PageSpeed, CrUX ou trace]


1. Identifique o elemento de LCP em cada cenário.
2. Separe TTFB, atraso de descoberta, download e atraso de renderização.
3. Confirme se a imagem aparece no HTML inicial e se usa lazy loading.
4. Verifique prioridade, preload, dimensões e variante responsiva.
5. Proponha uma mudança pequena e preserve alt, proporção e qualidade visual.
6. Rode a build e mostre como repetir o mesmo teste antes de publicar.

O melhor ajuste não é o que adiciona mais hints. É o que remove o maior intervalo do caminho observado e continua funcionando quando a página muda de largura, versão e domínio.