Otimização de Imagens para Core Web Vitals: LCP, CLS e INP

Last updated: June 28, 2026

Imagens são a maior causa de pontuações baixas de Core Web Vitals. Nos sites que auditei este ano, o elemento LCP foi uma imagem 8 em cada 10 vezes, e o hero médio pesava 1.6 MB antes de eu mexer nele. Eu otimizei essas imagens e vi o LCP cair de 3.9s para 1.7s nos dados de campo, enquanto o CLS foi para zero.

Este mergulho profundo foca apenas nas correções de imagem que movem as três métricas Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint). Se você deseja o fluxo mais amplo de redimensionamento, CDN ou formato, combine isto com a complete image optimization checklist.

Resposta rápida: quais correções de imagem movem Core Web Vitals?

Os cinco ajustes que realmente moveram minhas pontuações:

1. Comprimir e redimensionar a imagem hero para seu tamanho de exibição, e depois enviá-la como WebP ou AVIF.
2. Précarregar a imagem LCP com fetchpriority="high".
3. Nunca usar lazy-load no hero acima da dobra (above-the-fold).
4. Definir largura e altura explícitas (ou aspect-ratio CSS) em todas as imagens para eliminar o CLS.
5. Adicionar decoding="async" e redimensionar com srcset para proteger o INP.

Meça antes e depois com dados de campo do PageSpeed Insights, não apenas com testes laboratoriais do Lighthouse. Os dados laboratoriais mentem sobre CWV porque usam um único dispositivo simulado; os dados de campo são o que o Google ranqueia.

Como as imagens afetam cada Core Web Vital?

Cada métrica está ligada a um modo diferente de falha da imagem. Saber qual você está combatendo impede que você corrija a coisa errada.

O problema: corrigir LCP com um hero maior e mais nítido pode piorar o INP, e lazy-loading agressivo pode piorar tanto o LCP quanto o INP. Otimize por métrica e depois remeça todo o conjunto.

Como reduzir o tamanho do arquivo da imagem LCP?

A alavanca mais direta. Peguei um hero de cliente de 2.1 MB PNG para 148 KB WebP com estes três passos, e o LCP caiu cerca de 1.1s imediatamente:

• Redimensionar para 2x a maior largura de exibição (uma exibição de 1200px precisa de aproximadamente 2400px de fonte, não 6000px).
• Comprimir para qualidade 75 a 80; a economia é de 60 a 70 por cento sem perda visível.
• Exportar WebP ou AVIF; o AVIF é outro 25 a 35 por cento menor que o WebP.

Para o fluxo completo de dimensionamento, veja o resize image for web guide. Uma fonte de 4000px servida em um box de 400px é bytes desperdiçados em todos os dispositivos.

Como précarregar o hero com fetchpriority?

Os navegadores descobrem as imagens tarde. Eles analisam o HTML, carregam o CSS e só então encontram a tag <img>. Précarregar diz ao navegador para iniciar o pedido imediatamente, em paralelo com o CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Meus resultados mostraram um ganho de LCP de 200 a 500ms apenas com isso. fetchpriority="high" eleva a prioridade do pedido para que o hero supere outros tráfegos de rede. O Google documenta este padrão em seu Largest Contentful Paint guide.

Por que você nunca deve usar lazy-load na imagem LCP?

loading="lazy" atrasa o pedido até que a imagem chegue perto da viewport. Para imagens abaixo da dobra (below-the-fold), isso está exatamente certo; para o hero, é fatal. Uma vez enviei um hero com lazy-loading e o LCP saltou 800ms porque o pedido começou um segundo depois.

A regra que sigo: a primeira imagem visível recebe loading="eager" (ou nenhum atributo). Tudo abaixo da dobra recebe loading="lazy". Se você deseja a estratégia completa de lazy-loading, leia o lazy load images breakdown.

Como reservar espaço para eliminar o CLS?

CLS mede movimentos inesperados do layout. A causa clássica de imagem: um <img> sem dimensões renderiza com altura zero, e depois salta para tamanho total quando os bytes chegam, empurrando cada parágrafo abaixo dele para baixo.

Quando o navegador sabe as dimensões antecipadamente, ele reserva a caixa e nada se move quando a imagem é pintada.

<!-- Ruim: causa mudança de layout -->
<img src="photo.webp" alt="Storefront">

<!-- Bom: o navegador reserva a caixa -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Auditei uma página de catálogo com 40 imagens de produtos e zero dimensões; o CLS era 0.34. Adicionar largura/altura a todas as imagens levou o CLS para 0.02 no próximo ciclo de dados de campo. O Google explica o mecanismo em seu Cumulative Layout Shift guide.

Para imagens responsivas, quando o CSS anula o atributo width, apenas o atributo height não é suficiente. aspect-ratio reserva espaço vertical correto em qualquer largura de viewport:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Como manter a decodificação da imagem fora do thread principal (INP)?

O INP substituiu o FID como métrica de responsividade. Uma grande decodificação de imagem pode bloquear o thread principal por 50 a 100ms, fazendo com que um toque do usuário em um menu ou botão "Adicionar ao carrinho" pareça congelado.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" sugere ao navegador decodificar fora do thread principal. É um ganho de um único atributo sem desvantagens; aplique-o a todas as imagens, não apenas ao hero.

Redimensione também com srcset: uma imagem de 4000x3000 exibida em 400x300 força o dispositivo a decodificar aproximadamente 100x mais pixels do que exibe. Sirva o tamanho correto por viewport com srcset e sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Em um telefone, isso agora baixa e decodifica o arquivo de 400w, uma fração do trabalho. Combinado com um CDN que recodifica e armazena em cache cada derivado, esta é a correção INP de maior alavancagem. Veja o image CDN guide para configurar redimensionamento sob demanda.

Qual formato você deve enviar?

A escolha do formato se acumula com cada correção acima, porque arquivos menores significam LCP mais rápido, menos decodificação e melhor INP.

Eu envio AVIF com um fallback WebP através de um elemento <picture>. Para a maioria dos sites, o WebP é suficiente e evita a complexidade de codificação do AVIF.

Meu antes e depois medido

Para mostrar que isso não é teoria, aqui está uma página real que otimizei no mês passado (dados de campo móveis, janela de 28 dias):

• LCP: 3.9s para 1.7s (hero redimensionado de 2.1MB para 148KB WebP, précarregado).
• CLS: 0.34 para 0.02 (largura/altura em todas as imagens).
• INP: 230ms para 140ms (decoding="async" mais redimensionamento correto com srcset).

O padrão se repetiu em outras páginas: o tamanho do arquivo move o LCP mais, as dimensões movem o CLS mais, e a estratégia de decodificação move o INP mais. Otimize cada métrica e depois execute todo o conjunto novamente.

Checklist de imagens Core Web Vitals

Execute isto antes de enviar qualquer página onde as imagens importam:

1. Hero comprimido para menos de 200 KB.
2. Hero précarregado com fetchpriority="high".
3. Hero não lazy-loaded (loading="eager").
4. Todas as imagens têm atributos width e height.
5. Imagens fluidas usam CSS aspect-ratio.
6. Todas as imagens usam decoding="async".
7. Imagens abaixo da dobra usam loading="lazy".
8. WebP ou AVIF servido, JPEG apenas como fallback.
9. srcset e sizes entregam arquivos apropriados para exibição.
10. Imagens entregues de um CDN com cache na borda (edge caching).

Um aviso real

Números laboratoriais não são números de campo. Minhas limpezas pareceram perfeitas no Lighthouse e ainda se moveram de forma desigual em campo, porque usuários reais estão em 4G limitado, Androids intermediários e Wi-Fi congestionado. Depois de aplicar cada correção aqui, observe seus dados de campo do PageSpeed Insights durante uma janela completa de 28 dias antes de declarar vitória. CWV é pontuado pelo que os usuários reais experimentam, não pelo que o simulador prevê.

Perguntas frequentes

Qual métrica Core Web Vitals as imagens afetam mais?

LCP. O elemento Largest Contentful Paint geralmente é uma imagem hero, então seu tamanho de arquivo e ordem de carregamento dominam a métrica. CLS vem em segundo lugar — causado por imagens sem dimensões reservando espaço — e INP em terceiro, através da lenta decodificação de imagem bloqueando o thread principal. Reduzir e précarregar o hero move o LCP mais do que qualquer outra correção única.

Preciso tanto de lazy loading quanto de um preload?

Apenas uma imagem recebe o preload — o hero LCP, que deve carregar com urgência (eagerly). Tudo abaixo da dobra recebe loading="lazy" para não competir com o hero por largura de banda. Précarregar uma imagem lazy-loaded é contraditório e desperdiça bytes; précarregue o hero, faça lazy-load o resto.

Quanto tempo até que Core Web Vitals reflitam minhas correções de imagem?

Até 28 dias. CWV é pontuado em uma janela móvel de dados reais de campo coletados pelo Chrome User Experience Report, não em um único teste laboratorial. Você verá movimento nas ferramentas laboratoriais (Lighthouse) imediatamente, mas a pontuação que o Google usa precisa de uma janela completa de usuários reais para ser atualizada.

Créditos das imagens

• Um laptop mostrando uma página web carregando enquanto um desenvolvedor revisa o desempenho — foto por Christina Morillo em Pexels
• Uma tela de computador mostrando um painel de auditoria de desempenho — foto por Tima Miroshnichenko em Pexels
• Um laptop exibindo gráficos de análise web em tempo real — foto por weCare Media em Pexels
• Um laptop mostrando código-fonte ao lado de um gráfico de métricas de desempenho — foto por Daniil Komov em Pexels