Como melhorar o LCP otimizando imagens
Na maioria das páginas, o elemento LCP é uma imagem. Otimizá-la bem é a forma mais direta de passar de "Precisa de melhoria" para "Bom" nos Core Web Vitals.
O que é o LCP e por que ele depende das imagens
O Largest Contentful Paint (LCP) mede quanto tempo leva para aparecer o maior elemento visível na janela ao carregar a página. O Google considera bom um LCP de 2,5 segundos ou menos no percentil 75 das visitas reais, e ele é uma das três métricas dos Core Web Vitals, junto com o INP e o CLS.
Na grande maioria das páginas —páginas iniciais, páginas de produto, artigos— esse elemento é uma imagem: o banner principal, a foto do produto ou a imagem de destaque do post. Por isso, melhorar o LCP quase sempre significa melhorar como uma imagem específica é carregada.
As quatro fases do LCP
O tempo de LCP pode ser dividido em quatro partes. Identificar a mais longa diz o que otimizar:
- Tempo até o primeiro byte (TTFB): quanto o servidor demora para responder com o HTML.
- Atraso de carregamento do recurso: tempo entre o TTFB e o momento em que o navegador começa a baixar a imagem.
- Duração do carregamento do recurso: quanto a imagem demora para ser baixada.
- Atraso de renderização: tempo entre o fim do download e a pintura da imagem.
As imagens afetam sobretudo as fases 2 e 3. Uma referência útil do Google: em uma página bem otimizada, as fases de atraso deveriam ser mínimas e a maior parte do tempo vai para o TTFB e o download.
Passo 1: encontre seu elemento LCP
Antes de otimizar, confirme qual é. Há várias formas:
- PageSpeed Insights ou Lighthouse: no diagnóstico "Elemento de Largest Contentful Paint" aparece o nó exato.
- Chrome DevTools > Desempenho: grave um carregamento e procure o marcador LCP na linha do tempo.
- Search Console > Core Web Vitals: mostra os grupos de URLs com problemas segundo dados reais de usuários.
O elemento LCP pode ser diferente no celular e no desktop. Confira os dois.
Passo 2: faça o navegador descobri-la cedo
O erro mais comum é a imagem LCP não estar no HTML inicial: ela é inserida com JavaScript, é um background-image do CSS ou depende de um slider que inicializa tarde. Nesses casos o navegador só consegue começar a baixá-la muito depois.
Soluções, da melhor para a pior:
- Use um
<img>normal no HTML servido pelo servidor. - Se precisar ser fundo CSS ou for carregada com JS, adicione um
<link rel="preload">:
<link rel="preload" as="image" href="/hero.avif" type="image/avif" fetchpriority="high">
Se você usa imagens responsivas, o preload aceita imagesrcset e imagesizes para pré-carregar a variante correta.
Passo 3: dê prioridade alta a ela
Por padrão, o navegador baixa as imagens com prioridade baixa até saber que estão visíveis. O atributo fetchpriority="high" indica desde o início que esta é importante:
<img src="/hero.avif" fetchpriority="high" width="1600" height="900" alt="…">
E o mais importante: nunca coloque loading="lazy" na imagem LCP. O carregamento adiado atrasa o download até o navegador calcular o layout, e é uma das causas mais frequentes de LCP lento. No guia sobre lazy loading e fetchpriority você encontra os detalhes.
Passo 4: reduza o peso
Com a imagem já descoberta e priorizada, o tempo de download depende dos bytes. Aqui entra a otimização:
- Dimensões corretas. Se a imagem é exibida a 1200 px, não sirva 4000 px. Use
srcsetpara oferecer vários tamanhos. - Formato moderno. O AVIF costuma reduzir o peso em 40-50% em relação ao JPEG. Use
<picture>com WebP ou JPEG de fallback. - Qualidade razoável. Para uma imagem principal, AVIF 55-65 ou WebP 80 costumam ser indistinguíveis do original.
Uma imagem LCP de 400 KB em JPEG pode ficar com 120-180 KB em AVIF. Em uma conexão 4G média, isso significa centenas de milissegundos a menos.
Passo 5: evite atrasos de renderização
Mesmo que a imagem já tenha chegado, ela pode demorar para ser pintada se:
- Houver CSS ou JavaScript bloqueantes que atrasam a primeira renderização.
- A imagem estiver inicialmente oculta (por exemplo, um carrossel que a mostra com uma animação).
- Uma fonte web atrasar o texto e, com ele, o layout.
Mantenha o CSS crítico pequeno, adie o JavaScript não essencial e evite animações de entrada na imagem principal.
Erros frequentes
loading="lazy"na primeira imagem visível.- Hero como
background-imagesem preload. - Servir a mesma imagem de 2500 px para celulares.
- Sliders que carregam todos os slides com a mesma prioridade.
- CDNs de imagens com redirecionamentos ou em um domínio diferente sem
preconnect.
Perguntas frequentes
Quanto o LCP melhora ao mudar para AVIF?
Depende da conexão e do peso original, mas se a imagem representa a maior parte do tempo de carregamento, reduzir seu tamanho pela metade pode cortar centenas de milissegundos no celular.
Devo usar preload e fetchpriority ao mesmo tempo?
Se a imagem já está no HTML como <img>, basta fetchpriority="high". O preload é útil quando o navegador não consegue descobri-la cedo.
O texto pode ser o elemento LCP?
Sim. Se o maior bloco for um título, o LCP depende sobretudo do TTFB e do carregamento das fontes, não de imagens.
Por que o Lighthouse e o Search Console dão resultados diferentes?
O Lighthouse é um teste de laboratório em condições simuladas. O Search Console usa dados reais de usuários (CrUX) dos últimos 28 dias. As mudanças levam algumas semanas para aparecer nos dados reais.