Como reduzir o LCP: onde o tempo se perde antes do conteúdo aparecer

A página demora para mostrar o conteúdo principal e ninguém sabe por quê. Esse atraso tem nome: LCP, a marca do instante em que o maior bloco visível da área inicial termina de ser desenhado. Segundo a documentação do Google, abaixo de 2,5 segundos é considerado bom.

O erro mais caro em performance é começar comprimindo tudo. Time gasta duas semanas otimizando 200 imagens do site e o indicador não se move, porque o elemento medido era um bloco de texto travado por uma fonte customizada. Otimizar sem identificar o alvo é sorte, não método.

Vale dizer o que o LCP não é. Ele não mede a página inteira carregada, nem o momento em que o último script terminou. Mede um único elemento, o maior visível na primeira tela, e só ele.

Este artigo faz o caminho inverso: primeiro descobrir qual elemento está sendo cronometrado, depois quebrar o tempo em quatro partes e atacar cada uma com a técnica certa. É trabalho de eliminação, e cada parte tem sintoma próprio.

Qual elemento da sua página está sendo medido?

O navegador escolhe sozinho o maior elemento de conteúdo visível na primeira tela, e é ele que define o LCP daquela página. Costuma ser uma imagem de herói, o pôster de um vídeo, um plano de fundo aplicado por CSS ou um bloco grande de texto — normalmente o título e o parágrafo de apoio.

Duas consequências práticas. A primeira: cada página tem o seu elemento, e a home não serve de amostra para a página de produto. A segunda: o elemento muda entre celular e desktop, porque a área visível muda. Uma imagem lateral que domina a tela do notebook pode nem aparecer na primeira dobra do celular.

Para descobrir qual é, rode o PageSpeed Insights na URL e abra o item que aponta o maior elemento de conteúdo — ele mostra o seletor exato. No Chrome DevTools, o painel de performance marca o candidato na linha do tempo. Faça isso no perfil de celular, que é o que decide a nota.

Anote também o tamanho real do elemento

Se a resposta for uma imagem, compare a largura que ela ocupa na tela com a largura do arquivo entregue. É comum encontrar um arquivo de 2.400 pixels servindo um espaço de 380. O visitante baixa quatro vezes mais bytes do que precisa e paga isso em segundos de rede móvel.

As quatro subpartes do LCP

O tempo total se divide em quatro trechos consecutivos. Somados, dão o LCP final. Diagnosticar é descobrir qual deles está comendo o orçamento — e a resposta quase nunca está distribuída por igual.

Tempo de resposta do servidor

É o intervalo entre o clique e o primeiro byte do documento chegar. Nada pode começar antes disso. Se esse trecho já consome 1,2 segundo, sobra pouco para o resto, e nenhuma otimização de imagem compensa: o LCP herda esse atraso inteiro.

Causas comuns: página montada do zero a cada visita sem cache, consulta de banco pesada no carregamento, servidor geograficamente distante do público, redirecionamento em cadeia antes do documento final. Cache de página e CDN resolvem a maioria dos casos.

Atraso para descobrir o recurso

O navegador só baixa a imagem depois de saber que ela existe. Se a referência está dentro de um arquivo CSS, de um script ou de um componente que só monta depois da execução do JavaScript, a descoberta acontece tarde.

O sintoma é claro no gráfico de rede: um espaço vazio entre o fim do documento e o início do download da imagem. Esse buraco é tempo puro, e some quando a imagem vira uma tag no HTML inicial ou ganha um preload no cabeçalho.

Tempo de baixar o recurso

Aqui sim entra peso de arquivo. Formatos modernos como WebP e AVIF reduzem bastante o tamanho com qualidade visual equivalente. Dimensione a imagem para o maior espaço em que ela aparece, use srcset para entregar versões menores no celular e evite PNG em fotografia.

Atraso de renderização

O recurso já chegou, mas a tela não mostra. Isso acontece quando uma folha de estilo ainda está bloqueando, quando a fonte não carregou e o texto está invisível, ou quando o elemento depende de um script para sair de opacity: 0.

Preload e fetchpriority: quando cada um vale

O navegador atribui prioridades sozinho, e ele erra com frequência na imagem do topo — por padrão, imagens começam com prioridade baixa até o layout confirmar que estão na área visível.

Duas ferramentas corrigem isso. fetchpriority="high" na tag da imagem de herói promove o download na fila: uma linha de HTML, sem custo, e costuma ser o ajuste de melhor retorno da lista. Use em exatamente uma imagem por página — promover tudo é o mesmo que não promover nada.

O preload no cabeçalho serve para quando a imagem não está no HTML, como um plano de fundo por CSS. Também é a ferramenta certa para a fonte do título da primeira tela.

Vale o alerta oposto: nunca coloque loading="lazy" na imagem do topo. O carregamento preguiçoso é ótimo para o que está abaixo da dobra e desastroso para o elemento do LCP, porque adia justamente o download que precisava ser o primeiro. A relação entre essas três métricas e o que cada uma cobra do time está detalhada no panorama das três métricas que o Google avalia.

Fontes bloqueiam a exibição do texto?

Bloqueiam, e esse é o caso em que o elemento medido é texto. Com o comportamento padrão, o navegador espera a fonte customizada chegar antes de desenhar as letras. Enquanto espera, a área fica em branco, e o cronômetro corre.

font-display: swap instrui o navegador a desenhar imediatamente com uma fonte do sistema e trocar depois. O texto aparece cedo. O custo é uma troca visível, que pode gerar deslocamento — o assunto de por que a troca de fonte mexe no layout já pintado.

Some duas medidas: hospede a fonte no seu próprio domínio, para eliminar uma conexão externa, e carregue apenas os pesos que a primeira tela usa. Três pesos de uma família são três arquivos na frente do conteúdo.

O erro que empurra o LCP para depois da hidratação

Este é o padrão mais destrutivo e o mais comum em sites feitos com foco em animação. O topo começa com opacity: 0 ou translateY(20px), e uma biblioteca de animação revela o bloco quando o script termina de executar.

O resultado é direto: o elemento só é considerado pintado quando fica visível. Um servidor rápido e uma imagem leve não salvam nada, porque o LCP passa a depender do momento em que o JavaScript terminou de rodar e hidratar a página. Em celular intermediário, isso adia tudo em um a dois segundos.

A mesma lógica atinge carrosséis que montam o primeiro slide por script, banners de consentimento que escondem o conteúdo atrás de uma camada e testes A/B que aplicam uma classe de ocultação até decidir a variante.

A correção é conceitual antes de técnica: o conteúdo da primeira tela precisa vir visível no HTML. Anime o que está abaixo da dobra, não o que está acima.

E o peso do JavaScript em si?

Um pacote grande atrasa a pintura mesmo sem esconder nada, porque compete por banda e ocupa a thread principal. Esse mesmo pacote é o principal responsável por travamento em cliques, tema tratado em como a régua de resposta a interações mudou em 2024.

Por onde começar quando o LCP está ruim

Uma sequência que evita desperdício:

1. Identifique o elemento do LCP no perfil de celular, na URL com mais tráfego.
2. Meça o tempo de primeira resposta do servidor. Se passar de meio segundo, resolva isso antes de qualquer coisa.
3. Garanta que o recurso do topo seja descoberto cedo: tag no HTML, fetchpriority="high", sem lazy.
4. Ajuste formato e dimensão do arquivo para o espaço real ocupado.
5. Elimine qualquer dependência de script para o topo ficar visível.
6. Publique e espere a janela de campo se renovar antes de concluir.

Os dois primeiros passos costumam entregar a maior parte do ganho. Os demais consolidam. Fazer na ordem inversa é o que produz aquele projeto de performance que consumiu um mês e melhorou 200 milissegundos.

O que não vale a pena atacar primeiro?

Minificar CSS, remover regras não usadas e trocar de biblioteca de ícones dão ganhos de dezenas de milissegundos. São ajustes legítimos de manutenção, e são os últimos da fila quando o LCP está em 4 segundos.

Da mesma forma, nota alta em laboratório não encerra o assunto: o dado que conta vem de usuários reais, com aparelhos e redes que você não escolhe. Avaliamos essa diferença logo no diagnóstico dos nossos projetos de sites com SEO técnico, porque ela decide se o esforço vai para o servidor, para as imagens ou para o JavaScript — e errar essa escolha custa o orçamento inteiro da frente de performance.