LCP lento: como encontrar o elemento responsável e corrigir a cadeia crítica

Leitura executiva

Principais conclusões

• O elemento de LCP pode mudar entre dispositivos e visitas.
• Decomponha o tempo antes de escolher a correção.
• Descubra o recurso cedo e priorize somente o candidato correto.
• Não use lazy-loading no elemento acima da dobra que determina o LCP.

Largest Contentful Paint (LCP) mede quando o maior elemento de conteúdo visível termina de renderizar. Corrigir a métrica exige mais do que “otimizar imagens”: é preciso identificar o elemento medido e descobrir em qual etapa o tempo está sendo gasto.

O limite recomendado é de 2,5 segundos no percentil 75 das visitas. Use campo e laboratório em conjunto: o primeiro confirma alcance; o segundo expõe a cadeia crítica.

Identifique o elemento de LCP

O candidato pode ser:

• imagem hero;
• imagem dentro de um carrossel;
• poster de vídeo;
• bloco de texto;
• imagem de fundo compatível com a medição;
• outro elemento grande no viewport inicial.

O elemento pode mudar entre mobile e desktop porque layout, recorte, texto e recursos são diferentes. Também pode mudar depois de um teste A/B, consentimento, personalização ou falha de carregamento.

Use o painel de Performance do Chrome, PageSpeed Insights ou instrumentação com web-vitals para registrar elemento e URL do recurso quando disponíveis. Não assuma que a imagem visualmente mais chamativa foi a candidata medida.

Decomponha o tempo do LCP

O tempo pode ser pensado em quatro partes.

Tempo até o primeiro byte

Inclui navegação, conexão, processamento do servidor e início da resposta do documento. Se o HTML começa tarde, todos os recursos descobertos a partir dele também começam tarde.

Investigue:

• redirecionamentos;
• ausência de cache adequado;
• renderização de servidor lenta;
• consulta de dados bloqueante;
• distância geográfica;
• cold starts;
• sobrecarga de middleware.

Atraso de descoberta do recurso

É o intervalo entre receber o HTML e o navegador descobrir o recurso de LCP. O atraso cresce quando a imagem:

• é inserida por JavaScript;
• depende de um carrossel hidratado;
• aparece apenas em CSS carregado tarde;
• usa atributo que impede prioridade adequada;
• fica atrás de uma chamada de API do cliente.

O melhor cenário é o candidato principal estar explícito no HTML inicial.

Duração da transferência

Depois de descoberto, o recurso precisa ser baixado. Peso, formato, dimensões, cache, CDN e conexão afetam essa etapa.

Atraso de renderização

O arquivo pode estar disponível e ainda não aparecer porque CSS, fontes, JavaScript ou trabalho da thread principal impedem o paint. Nesse caso, comprimir mais a imagem resolve apenas uma parte pequena.

Corrija o documento antes de acelerar o recurso

Um TTFB alto desloca toda a cascata. Antes de adicionar preloads, verifique se a página pode:

• eliminar redirecionamento de entrada;
• usar cache de página ou de dados;
• servir conteúdo estático quando apropriado;
• aproximar conteúdo do usuário com CDN;
• executar buscas independentes em paralelo;
• adiar trabalho que não é necessário para o HTML inicial.

Meça também o efeito sobre personalização e atualização. Cache incorreto pode servir dados obsoletos ou privados.

Faça o navegador descobrir o candidato cedo

Renderize a primeira imagem do hero no HTML. Use srcset e sizes para que o navegador escolha uma variante adequada:

<img
  src="/hero-1280.webp"
  srcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  alt="Diagnóstico priorizado de um website"
  fetchpriority="high"
>

fetchpriority="high" pode ajudar a sinalizar importância, mas use-o apenas no candidato provável. Marcar várias imagens como alta prioridade reduz o valor do sinal.

Para imagens descobertas por CSS ou outros caminhos tardios, um preload pode ser apropriado. Confirme no waterfall que ele antecipa a requisição e que a mesma URL não é baixada duas vezes por incompatibilidade de atributos.

Não aplique lazy-loading ao LCP acima da dobra

loading="lazy" adia recursos considerados fora ou perto do viewport. No candidato de LCP visível no carregamento, esse adiamento costuma ser contraproducente.

Mantenha lazy-loading para imagens abaixo da dobra. Verifique variações responsivas: uma imagem que está abaixo da dobra no desktop pode se tornar candidata no mobile.

Sirva o arquivo certo

Reduza bytes sem destruir qualidade:

• gere dimensões próximas do espaço renderizado;
• use formatos modernos compatíveis com o projeto;
• comprima com inspeção visual;
• evite baixar imagem desktop para um viewport pequeno;
• configure cache duradouro para arquivos versionados;
• remova metadata desnecessária;
• não use GIF pesado quando vídeo ou animação vetorial for mais adequado.

O objetivo não é atingir o menor arquivo possível, mas equilibrar qualidade, custo de decodificação e transferência.

Remova bloqueios de renderização

Se o candidato é texto, fontes e CSS ganham importância. Garanta que estilos críticos cheguem cedo, evite folhas enormes bloqueando a primeira pintura e revise a estratégia de fontes.

Se JavaScript ocupa a thread principal durante o momento em que o recurso fica pronto, reduza trabalho inicial:

• renderize conteúdo no servidor;
• divida componentes não críticos;
• adie terceiros;
• evite hidratar áreas estáticas;
• reduza efeitos que recalculam layout no início.

Carrosséis exigem atenção especial

Carrosséis frequentemente escondem a primeira imagem atrás de JavaScript e carregam todos os slides com prioridade semelhante.

Uma implementação mais robusta:

1. renderiza o primeiro slide no HTML;
2. prioriza apenas sua imagem;
3. reserva dimensões;
4. carrega slides seguintes com prioridade menor;
5. mantém controles acessíveis;
6. não troca automaticamente o candidato antes do carregamento estabilizar.

Considere se o carrossel é necessário. Uma única mensagem principal costuma ser mais simples para performance e clareza.

Valide a correção

Repita o teste sob condições comparáveis e registre:

• elemento de LCP;
• URL do recurso;
• TTFB;
• início e fim da requisição;
• momento de renderização;
• bytes transferidos;
• tarefas longas próximas ao paint.

Teste páginas do mesmo template, não apenas o melhor caso. Depois acompanhe dados de campo e métricas de negócio sem presumir causalidade imediata.

Exemplo de tarefa pronta

Observação: no mobile, a imagem principal de produto é o LCP e começa a baixar somente após hidratação do carrossel. Ação: renderizar o primeiro slide no servidor com srcset, dimensões e prioridade alta; manter os demais slides sob demanda. Aceite: a imagem correta aparece sem JavaScript, não há download duplicado e o LCP de laboratório melhora na mediana de cinco execuções.

LCP lento é uma cadeia, não um arquivo. Quando você decompõe o tempo, a recomendação deixa de ser genérica e passa a atacar o componente que realmente domina a experiência.

Respostas diretas

Perguntas frequentes

Qual é um bom LCP?

A recomendação atual do Core Web Vitals é LCP de até 2,5 segundos no percentil 75 das visitas, separado entre mobile e desktop.

Preload sempre melhora LCP?

Não. Ele ajuda quando o recurso crítico seria descoberto tarde. Preloads excessivos competem por banda e podem piorar outros carregamentos.

Uma imagem comprimida resolve LCP?

Somente quando transferência é parte relevante do atraso. TTFB alto, descoberta tardia, CSS bloqueante ou renderização no cliente podem continuar dominando a métrica.