LCP: o que é e como reduzir o tempo de carregamento da página
O LCP é a métrica que diz quando a página parece pronta para o visitante. Veja como descobrir qual elemento está sendo medido, onde o tempo se perde e o que corrigir.
LCP, sigla de Largest Contentful Paint, é o tempo entre o início do carregamento e o momento em que o maior elemento visível da tela aparece por completo. Na maioria dos sites, esse elemento é a foto principal, o banner do topo ou um bloco grande de título. O LCP é bom quando fica em até 2,5 segundos em pelo menos 75% das visitas reais, e ruim acima de 4 segundos.
Para reduzir o LCP, não adianta só “deixar o site mais rápido” de forma genérica. O caminho é descobrir qual é o elemento medido, dividir o tempo dele em quatro partes (resposta do servidor, atraso para começar a baixar, tempo de download e atraso para aparecer) e corrigir a parte que está maior. É o que mostramos a seguir.
Se você ainda não conhece as três métricas de experiência do Google, comece pelo nosso artigo sobre Core Web Vitals. Aqui o assunto é só o LCP, em profundidade.
O que conta como “maior elemento”
O navegador considera, entre os elementos que aparecem na área visível da tela sem rolar:
- Imagens (<img> e imagens dentro de um SVG).
- A imagem de capa de um vídeo, ou o primeiro quadro exibido.
- Elementos com imagem de fundo definida no CSS.
- Blocos de texto, como um título ou um parágrafo grande.
Alguns elementos são ignorados de propósito: os invisíveis (com opacidade zero), os que cobrem a tela inteira e parecem fundo, e imagens de baixíssima informação, como um retângulo de cor usado como espaço reservado.
Dois detalhes que confundem:
- O elemento pode mudar durante o carregamento. Se o título aparece primeiro e a foto grande chega depois, o LCP passa a ser a foto. Vale o maior elemento exibido até a primeira interação.
- A medição para quando o visitante interage. Um toque, uma rolagem ou uma tecla encerram a busca por novos elementos.
O elemento do LCP também pode ser diferente no celular e no computador. No celular, a tela estreita às vezes faz um bloco de texto ficar maior que a imagem.
Como descobrir qual é o elemento do LCP
- PageSpeed Insights. Na parte de diagnóstico, o relatório mostra qual elemento foi o LCP no teste, com uma miniatura, e quebra o tempo dele em partes. Nosso guia sobre como ler o PageSpeed Insights mostra onde fica cada item.
- Ferramentas do desenvolvedor do Chrome. No painel de desempenho, a visão de métricas ao vivo mostra o LCP e o elemento enquanto você navega. Grave um carregamento com a rede e o processador limitados para simular um celular.
- Dados de usuários reais. Para saber qual elemento é o LCP para os visitantes reais, é preciso medir no próprio site, por exemplo com a biblioteca web-vitals do Google enviando os dados para o Analytics. Em sites menores, os dois primeiros métodos costumam bastar.
As quatro partes do LCP
Quando o elemento é uma imagem, o tempo até ela aparecer pode ser dividido em quatro partes. O guia de otimização de LCP do web.dev sugere uma proporção de referência para cada uma:
| Parte | O que é | Proporção de referência |
|---|---|---|
| 1. Tempo até o primeiro byte (TTFB) | Do pedido da página até o servidor começar a enviar o HTML | cerca de 40% |
| 2. Atraso de carregamento | Do primeiro byte até o navegador começar a baixar a imagem do LCP | menos de 10% |
| 3. Tempo de carregamento | O download da imagem em si | cerca de 40% |
| 4. Atraso de renderização | Do fim do download até a imagem aparecer na tela | menos de 10% |
As proporções são orientação, não regra. A leitura prática é esta: quase todo o tempo deveria estar no servidor e no download. Se o atraso de carregamento ou o de renderização está grande, há tempo desperdiçado esperando, e geralmente é o que se corrige mais rápido.
Quando o elemento do LCP é texto, não existe download de imagem: as partes 2 e 3 somem, e o que pesa é o servidor e o que atrasa a exibição do texto, como estilos e fontes.
Um exemplo com números
Imagine a página de um produto com LCP de 4,2 segundos no celular, dividido assim:
- TTFB: 1,2 s
- Atraso de carregamento: 1,6 s
- Tempo de carregamento: 0,9 s
- Atraso de renderização: 0,5 s
O maior vilão não é o tamanho da imagem, que baixa em menos de um segundo. É o atraso de carregamento: o navegador passou 1,6 segundo sem saber que precisava daquela imagem. Isso costuma acontecer quando a foto é inserida por JavaScript, está num carrossel que só monta depois que o script roda ou tem carregamento adiado. Corrigindo só isso e levando o atraso para perto de 0,2 s, o LCP cai para cerca de 2,8 s. Com cache de página reduzindo o TTFB para 0,6 s, chega a 2,2 s, dentro da faixa boa, sem mexer na imagem.
Comprimir a foto, nesse caso, seria a última coisa a fazer.
Correções para cada parte
1. TTFB: o servidor
- Cache de página. Entregar o HTML pronto em vez de montá-lo a cada visita é a correção de maior efeito em sites WordPress e lojas virtuais.
- Hospedagem adequada, com servidor próximo do público ou com CDN.
- CDN também para o HTML, quando o serviço permite guardar páginas em cache nos servidores da rede.
- Menos redirecionamentos. Anúncio que aponta para http, que vai para https, que vai para www: cada salto soma tempo antes do primeiro byte.
O web.dev recomenda um TTFB de até 0,8 segundo como referência. As causas de servidor lento estão detalhadas no nosso artigo sobre site lento.
2. Atraso de carregamento: deixar a imagem ser descoberta cedo
- A imagem principal no HTML. Use uma tag <img> comum, presente no código que o servidor entrega, em vez de uma imagem injetada por JavaScript ou definida como fundo num arquivo CSS.
- Sem carregamento adiado na imagem do topo. O atributo loading=”lazy” é ótimo para imagens do meio para baixo, mas na imagem do LCP só atrasa. O web.dev é direto: nunca adie o carregamento da imagem do LCP.
- Prioridade alta. O atributo fetchpriority=”high” na imagem principal avisa o navegador para baixá-la antes de outras. Use em uma ou duas imagens por página, no máximo; prioridade alta em tudo é o mesmo que nenhuma.
- Pré-carregamento quando não houver alternativa. Se a imagem precisa mesmo vir de um CSS ou de um script, uma tag de pré-carregamento (link com rel=”preload”) no cabeçalho do HTML faz o navegador começar o download cedo.
- Carrossel com a primeira imagem pronta. A primeira foto do carrossel deve estar no HTML, sem depender do script do carrossel para aparecer.
3. Tempo de carregamento: imagem menor
- Dimensões compatíveis com o espaço exibido, com versões diferentes para celular e computador (atributos srcset e sizes).
- Formatos modernos, como WebP ou AVIF, com compressão ajustada.
- Imagem servida pelo mesmo domínio do site ou por uma CDN rápida. Imagem em outro domínio exige uma conexão nova, o que soma tempo.
- Menos disputa: se o navegador está baixando dez scripts ao mesmo tempo, a imagem divide a banda com eles.
4. Atraso de renderização: deixar a imagem aparecer
- Estilos e scripts que bloqueiam a renderização. O navegador não desenha nada antes de processar o CSS do cabeçalho e os scripts síncronos. Reduza o CSS crítico e use os atributos defer ou async nos scripts que não precisam rodar antes.
- Fontes. Se o LCP é um título, uma fonte web que demora pode deixar o texto invisível. Configure a exibição da fonte para mostrar uma fonte de reserva enquanto a principal carrega.
- Elementos escondidos por script. Efeitos de entrada que começam com o conteúdo invisível, temas que só mostram a página depois de um script e ferramentas de teste A/B que escondem a página até decidir a versão atrasam o LCP de propósito.
Situações típicas e o que fazer
| Situação | Parte afetada | Correção principal |
|---|---|---|
| Banner da home num carrossel montado por JavaScript | Atraso de carregamento | Primeira imagem no HTML, com fetchpriority=”high” |
| Foto principal com carregamento adiado | Atraso de carregamento | Remover o loading=”lazy” dessa imagem |
| Foto de produto com 2 MB | Tempo de carregamento | Redimensionar, comprimir, WebP ou AVIF |
| Imagem de fundo definida no CSS | Atraso de carregamento | Trocar por <img> ou pré-carregar |
| Título grande com fonte web lenta | Atraso de renderização | Fonte de reserva visível e pré-carregamento da fonte |
| Servidor lento em todas as páginas | TTFB | Cache de página, hospedagem, CDN |
Depois da correção
O teste de laboratório mostra o efeito na hora, mas a avaliação que importa usa dados reais de 28 dias. No relatório de Core Web Vitals do Search Console, use o botão de validação no problema de LCP: o Google acompanha as páginas durante 28 dias e confirma se a correção funcionou.
E acompanhe o resto: uma imagem que agora aparece mais cedo não deve fazer a página pular nem travar ao toque. As três métricas precisam estar boas ao mesmo tempo.
Nas lojas e sites que construímos, a imagem principal já sai com dimensões certas, prioridade alta e sem carregamento adiado, e o servidor com cache de página. Se o LCP do seu site está acima de 2,5 segundos, podemos fazer esse diagnóstico no serviço de desenvolvimento de sites ou, para e-commerce, no de lojas virtuais.
