Como melhorar o Largest Contentful Paint (LCP)

O Largest Contentful Paint (LCP) marca o instante em que o maior elemento visível dentro da janela de visualização termina de ser renderizado na tela. Não é uma métrica sobre o site inteiro carregado, nem sobre o HTML entregue: é sobre o elemento — geralmente uma imagem, um bloco de texto grande ou um vídeo com poster — que domina visualmente o que o usuário vê no primeiro momento. Por isso o LCP é o proxy mais próximo que existe hoje para responder a uma pergunta simples: quando a página pareceu pronta para quem estava esperando por ela?

Melhorar o LCP não é sobre otimizar tudo ao mesmo tempo. É sobre identificar corretamente qual elemento o navegador está contando como o maior, entender em qual das quatro fases do carregamento o tempo está sendo perdido, e aplicar a correção que pertence àquela fase — nessa ordem. Pular direto para "comprimir imagens" sem antes confirmar qual imagem é a LCP é o motivo mais comum de otimizações que não movem o número.

O que o LCP mede, de verdade

O navegador observa continuamente os elementos renderizados na viewport durante o carregamento e mantém um registro do maior deles em termos de área visível. Cada vez que um elemento maior aparece — uma imagem que termina de decodificar, um bloco de texto que se torna visível, um vídeo cujo poster carrega — esse registro é atualizado. Quando a página para de produzir elementos maiores, normalmente após a primeira interação do usuário ou quando o carregamento se estabiliza, o último elemento registrado é o LCP, e o tempo entre o início da navegação e o momento em que esse elemento terminou de renderizar é o valor reportado.

Os candidatos possíveis para elemento LCP são limitados por especificação: elementos de imagem, elementos de imagem dentro de um SVG, o frame de poster de um elemento de vídeo, um elemento com uma imagem de fundo definida via CSS, e blocos de texto que contenham nós de texto diretamente visíveis, como um título ou parágrafo grande. Ícones pequenos, elementos de navegação e imagens abaixo da dobra praticamente nunca são o candidato — e é exatamente por isso que otimizar a imagem errada não move o LCP nem um pouco.

Como descobrir qual é o seu elemento LCP

Antes de qualquer otimização, confirme qual elemento o navegador está de fato contando. Adivinhar é a causa mais comum de esforço desperdiçado: uma equipe passa dias comprimindo o banner do topo enquanto o elemento LCP real é, por exemplo, o título principal renderizado com uma fonte customizada que ainda não carregou.

Vale revisar esse elemento periodicamente, não só uma vez: uma mudança de layout, um novo componente de topo ou um breakpoint responsivo diferente pode trocar qual elemento é o maior — especialmente entre mobile e desktop, que frequentemente têm elementos LCP diferentes na mesma URL.

• No Chrome DevTools, na aba Performance, grave o carregamento e procure a marcação de LCP na trilha de timings — ela aponta diretamente para o elemento no DOM.
• O relatório do PageSpeed Insights e o Lighthouse listam o elemento LCP na seção de diagnóstico, com um destaque visual sobre ele.
• A extensão de Web Vitals do Chrome sobrepõe um indicador na própria página em tempo real, mostrando o elemento e o valor no momento em que ele é definido.
• Em páginas de produto ou landing pages, o candidato mais comum costuma ser a imagem principal do topo ou o bloco de texto de destaque acima da dobra, mas isso muda por template — confirme por página, não por suposição.

As quatro fases que compõem o tempo de LCP

O tempo total de LCP se decompõe em quatro fases, e cada uma pede um tipo diferente de correção. Tratar o LCP como um número único e tentar melhorar tudo ao mesmo tempo é menos eficaz do que medir onde o tempo está concentrado e atacar essa fase especificamente.

Em páginas onde o LCP é um bloco de texto em vez de uma imagem, a fase de carregamento do recurso praticamente desaparece, e o problema quase sempre está concentrado no tempo de resposta do servidor ou no atraso de renderização — geralmente uma fonte customizada segurando a exibição do texto.

• Tempo até o primeiro byte: do início da navegação até o navegador receber o primeiro byte de resposta do servidor.
• Atraso de carregamento do recurso: do primeiro byte do documento até o navegador começar a buscar o recurso do elemento LCP, como a imagem.
• Tempo de carregamento do recurso: quanto tempo o próprio recurso leva para baixar, do início ao fim da transferência.
• Atraso de renderização: do fim do download do recurso até o elemento efetivamente aparecer na tela, incluindo processamento de CSS, execução de script bloqueante e o trabalho de layout e pintura.

Fase 1: tempo até o primeiro byte

O tempo até o primeiro byte é o piso de tudo o que vem depois — nenhuma otimização de imagem compensa um servidor que demora mais de um segundo só para começar a responder. As causas mais comuns são hospedagem subdimensionada, ausência de cache no lado do servidor para páginas que poderiam ser servidas de forma estática ou semiestática, consultas de banco de dados custosas disparadas a cada requisição, e cadeias de redirecionamento — cada salto de redirecionamento, seja de HTTP para HTTPS, de sem-www para com-www, ou de uma URL antiga para a atual, adiciona uma viagem de ida e volta completa antes mesmo do primeiro byte do documento final chegar.

Uma rede de distribuição de conteúdo bem configurada, servindo o HTML já processado a partir de um ponto próximo do visitante, costuma ser a alavanca isolada de maior impacto no tempo de resposta para sites com tráfego internacional. Para sites com conteúdo dinâmico, cache de página em nível de aplicação, mesmo que por poucos minutos, para visitantes não autenticados reduz drasticamente o tempo de resposta sem sacrificar a atualização do conteúdo.

Fases 2 e 3: por que o preload da imagem LCP importa tanto

Depois que o HTML chega, o navegador precisa descobrir que a imagem LCP existe antes de começar a baixá-la. Se essa imagem estiver referenciada só dentro de uma folha de estilo, como imagem de fundo via CSS, ou inserida por script depois que o próprio script carrega e executa, o navegador perde um tempo precioso — o atraso de carregamento do recurso — só para descobrir que precisa buscar esse arquivo.

A correção mais direta é declarar explicitamente ao navegador que aquele recurso é prioritário, usando uma tag de preload no cabeçalho do documento apontando para a imagem, combinada com o atributo de prioridade de busca alta na própria tag da imagem. Isso move a descoberta do recurso para o mais cedo possível no processo de leitura do HTML, em vez de depender de o navegador varrer o CSS ou executar script primeiro.

Para o tempo de download do próprio recurso, na terceira fase, o que importa é o tamanho do arquivo transferido: compressão adequada, um formato eficiente e, quando fizer sentido, servir a partir de uma rede de distribuição de conteúdo com boa proximidade geográfica do visitante.

O erro clássico: lazy-loading na imagem LCP

Aplicar carregamento preguiçoso universalmente em todas as imagens de um template é uma prática comum de otimização — e uma regressão autoinfligida quando o alvo é a própria imagem LCP. Esse atributo instrui o navegador a adiar o carregamento até que o elemento esteja próximo da viewport, o que é exatamente o oposto do que se quer para o elemento que já está visível no primeiro segundo da página. O resultado prático é uma imagem que só começa a ser buscada depois que o navegador termina de calcular o layout, empurrando o LCP para trás em vez de para frente.

A regra prática: nunca aplique carregamento preguiçoso na imagem que aparece acima da dobra ou que é candidata a elemento LCP. Reserve essa técnica para imagens que realmente estão fora da viewport inicial — a galeria no meio do artigo, o carrossel de produtos relacionados no rodapé. Muitos temas e construtores de página aplicam carregamento preguiçoso por padrão a todas as imagens de um template, incluindo a do topo — vale conferir esse comportamento explicitamente depois de qualquer atualização de tema ou plugin.

• Confirme, elemento a elemento, se a imagem candidata a LCP tem carregamento preguiçoso ativado — remova essa configuração se tiver.
• Marque a imagem LCP com prioridade de busca alta explicitamente, mesmo sem lazy-loading, para reforçar a prioridade de download.
• Sirva a imagem já no tamanho exibido, com variações de largura para os diferentes breakpoints, em vez de depender do navegador para redimensionar uma imagem maior do que o necessário.
• Prefira formatos modernos como WebP ou AVIF, que produzem arquivos menores com qualidade visual equivalente à de JPEG ou PNG para a maioria dos casos de uso.

Fase 4: atraso de renderização — CSS e fontes bloqueantes

Mesmo com o recurso já baixado, o elemento só aparece na tela depois que o navegador termina de processar tudo o que bloqueia a renderização daquele ponto da página — normalmente folhas de estilo carregadas de forma síncrona no cabeçalho do documento e fontes customizadas que ainda não chegaram.

Para CSS, a prática que mais ajuda é extrair o CSS crítico, apenas as regras necessárias para renderizar o que aparece acima da dobra, e inseri-lo diretamente no cabeçalho do documento, deixando o restante da folha de estilo carregar de forma assíncrona ou diferida. Isso evita que o navegador espere por um arquivo CSS completo, com regras para componentes que nem estão visíveis ainda, antes de pintar qualquer coisa na tela.

Para fontes, quando o elemento LCP é texto, como um título, a fonte customizada frequentemente é o próprio gargalo da fase de renderização. A propriedade de exibição de fonte controla esse comportamento: o valor "swap" mostra imediatamente uma fonte de sistema como substituta e troca quando a fonte customizada carrega, evitando texto invisível — o efeito conhecido como flash de texto invisível. Já o comportamento padrão do navegador pode manter o texto oculto por até alguns segundos esperando a fonte certa chegar. Fazer o preload das uma ou duas fontes usadas no conteúdo acima da dobra reduz ainda mais essa espera.

Dados de campo vs. dados de laboratório: qual número conta

Ferramentas como Lighthouse e o PageSpeed Insights, na aba de auditoria, rodam em um ambiente controlado, com uma conexão e um dispositivo simulados — isso é dado de laboratório. É extremamente útil para diagnóstico, porque é reproduzível e permite comparar antes e depois de uma mudança específica. Mas não é o número que qualquer sistema de avaliação de experiência de página usa para julgar o site.

O dado de campo vem de visitantes reais, em dispositivos reais, em condições de rede reais, coletado via relatório de experiência do usuário do Chrome ou via instrumentação própria no site, o chamado monitoramento de usuário real. Esse dado de campo é o que aparece no relatório de Core Web Vitals do Search Console e é o que reflete a experiência real de quem usa o site: alguém em uma conexão móvel lenta, com um celular de entrada, em uma região distante do servidor, terá um LCP muito diferente do medido em laboratório em uma máquina de desenvolvimento com fibra.

Por isso, uma página pode passar no Lighthouse local e ainda assim mostrar um LCP ruim no relatório de campo — e é o número de campo que deve orientar a priorização. Use o dado de laboratório para depurar uma mudança específica; use o dado de campo, segmentado por dispositivo quando possível, para decidir se a mudança realmente importou para os usuários reais.