Se o seu site parece lento, as imagens são o primeiro lugar para olhar. Na maioria dos sites, elas representam mais peso total de página do que todos os outros recursos somados — HTML, CSS e JavaScript incluídos. Isso também as torna o ponto de maior alavancagem para corrigir, já que um punhado de imagens bem comprimidas pode tirar segundos de um carregamento que uma dúzia de pequenos ajustes de código não conseguiria.

Onde as imagens realmente doem

Os Core Web Vitals do Google são as métricas de velocidade que entram no ranking de busca. São três, e as imagens afetam duas diretamente:

Métrica	Limite "bom"	As imagens afetam?
Largest Contentful Paint (LCP)	abaixo de 2,5 s	Diretamente, e quase sempre de forma decisiva
Cumulative Layout Shift (CLS)	abaixo de 0,1	Sim, mas pela marcação, não pelo peso
Interaction to Next Paint (INP)	abaixo de 200 ms	Só indiretamente

O LCP mede quanto tempo o maior elemento visível leva para renderizar. Na maioria das páginas esse elemento é uma imagem: um banner de topo, uma foto de produto, a imagem de capa de um post. Uma imagem pesada é a causa isolada mais comum de um LCP que não passa.

O CLS mede quanto o layout salta durante o carregamento. Isso não tem nada a ver com o tamanho do arquivo: acontece quando uma imagem chega sem as dimensões declaradas, então o navegador só descobre quanto espaço ela precisa depois que todo o resto já foi posicionado.

O INP mede a resposta à interação, e as imagens tocam nisso só de raspão: uma imagem muito grande custa tempo de thread principal para decodificar, o que pode atrasar a resposta a um toque enquanto isso acontece.

Um detalhe que evita muita confusão: o Google avalia isso no percentil 75 de usuários reais numa janela móvel de 28 dias, via Chrome User Experience Report. Você só passa quando pelo menos 75% das visualizações reais atingem o limite. É por isso que uma pontuação perfeita no Lighthouse e um relatório vermelho no Search Console convivem tranquilamente — mais sobre isso adiante.

O que um megabyte custa em segundos

Esta é a parte que torna a troca concreta. O perfil móvel padrão do Lighthouse limita a conexão a 1,6 Mbps com 150 ms de latência — uma conexão deliberadamente sem graça, mais ou menos o quarto mais lento do 4G. Nessa velocidade chegam cerca de 195 KB por segundo.

Pegue a curva de qualidade JPG que medimos em como comprimir imagens sem perder qualidade e converta os tamanhos em tempo de transferência:

Qualidade	Tamanho	Tempo de transferência a 1,6 Mbps
100	1220 KB	6,25 s
95	402 KB	2,06 s
90	234 KB	1,20 s
85	151 KB	0,77 s
80	118 KB	0,60 s
70	75 KB	0,38 s

Agora coloque isso contra um orçamento de LCP de 2,5 segundos — e lembre que o orçamento tem que cobrir tudo, não só a imagem: DNS, estabelecimento de conexão, resposta do servidor, parsing do HTML, CSS, e só então o download da imagem.

Na qualidade 100, a imagem sozinha estoura o orçamento inteiro por quase quatro segundos. Em 95 ela consome mais de 80% dele. Em 85 ocupa menos de um terço e deixa espaço real para todo o resto. É a mesma economia de um único passo, de 100 para 95, do artigo de compressão, reformulada como a diferença entre passar e não passar.

Duas ressalvas para os números continuarem honestos. Nossa imagem de teste tem bastante grão, então os tamanhos absolutos saem mais altos que numa foto típica de celular: o que se transfere são as proporções, os KB são ilustrativos. E uma conexão real não é um tubo constante: a imagem normalmente nem consegue começar a baixar até o HTML ter sido processado, o que deixa o quadro prático um pouco pior que a tabela, não melhor.

Daí sai um orçamento de peso para a página

Inverta essa aritmética e ela se torna um número com o qual você pode realmente projetar. A 195 KB por segundo, um orçamento de LCP de 2,5 segundos compra cerca de 490 KB no total — e esse total cobre o HTML, o CSS, qualquer JavaScript bloqueante e as fontes, antes de gastar um único byte de imagem.

Digamos que o esqueleto da página custe 150 KB. Sobram cerca de 340 KB para tudo que renderiza acima da dobra. Uma imagem de topo na qualidade 85 (151 KB na nossa tabela) cabe com folga. Três não.

Essa também é a resposta para "quantas imagens são demais". Uma página de galeria com dez fotos de 118 KB cada dá 1,18 MB — seis segundos de transferência nessa conexão, antes de qualquer outra coisa carregar. A correção não é comprimir cada uma com mais força, é carregar duas e deixar as outras oito em carregamento diferido, para que só o que está visível dispute o orçamento.

Duas coisas devolvem folga fora do orçamento. Cache significa que quem volta não paga nada pelas imagens que já tem, então configure tempos longos de Cache-Control em arquivos cuja URL muda quando o conteúdo muda. E uma CDN encurta a ida e volta, não o tamanho: esses 150 ms de latência são por requisição, e são pagos em todas elas.

A ordem que importa

Três alavancas, e não têm a mesma força. Puxe nesta ordem:

Redimensione para o tamanho real de exibição. Uma foto de 4000 pixels de largura numa coluna de 600 baixa os dados de todos os 4000 pixels para o navegador jogar quase tudo fora. Nenhum ajuste de qualidade recupera isso. É o maior ganho isolado e o que mais gente pula.
Troque de formato. O WebP normalmente fica de 25% a 35% abaixo de um JPG equivalente com a mesma qualidade visual, e o AVIF ainda mais. Os dois são seguros de exibir em qualquer navegador que ainda receba atualizações. (WebP vs JPG vs PNG vs AVIF cobre as contrapartidas.)
E então ajuste a qualidade. Nesse ponto você está otimizando um arquivo já razoável, que é exatamente a hora certa de fazer isso.

Quatro erros de entrega que estragam uma boa compressão

Você pode comprimir de forma impecável e continuar reprovando no LCP. É assim que acontece.

Carregar a imagem de topo em modo diferido. O gol contra mais comum de toda esta lista. loading="lazy" diz ao navegador que aquela imagem não é urgente — então aplicá-lo à sua imagem de LCP atrasa ativamente justo o que está sendo medido. Difira o que está abaixo da dobra; nunca o que está acima.

Não declarar as dimensões. Sempre defina width e height (ou um aspect-ratio no CSS). O navegador reserva o espaço correto antes de o arquivo chegar, e o CLS deixa de acontecer. Não custa nada e resolve uma métrica inteira.

Servir o mesmo tamanho para todo dispositivo. Um celular recebe o mesmo arquivo de 2000 pixels que um desktop. srcset com sizes deixa o navegador escolher:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="500"
  alt="…"
  fetchpriority="high"
/>

Esse fetchpriority="high" é a contraparte do erro do carregamento diferido: diz ao navegador para buscar esta primeiro, à frente das outras imagens que ele descobriu ao mesmo tempo.

Não oferecer formatos modernos com alternativa. O <picture> permite servir AVIF para quem suporta e cair para trás sem quebrar:

<picture>
  <source srcset="foto.avif" type="image/avif" />
  <source srcset="foto.webp" type="image/webp" />
  <img src="foto.jpg" width="800" height="500" alt="…" />
</picture>

O navegador pega o primeiro tipo que entende. Nada quebra em lugar nenhum.

Números de laboratório contra usuários reais

Vale entender antes de perseguir uma pontuação. Lighthouse e PageSpeed Insights rodam um teste de laboratório: um carregamento, um dispositivo simulado, uma conexão limitada. Determinístico e útil para achar problemas.

O relatório de Core Web Vitals do Search Console mostra dados de campo: visitantes reais, dispositivos reais, redes reais, agregados no percentil 75 ao longo de 28 dias. Outra pergunta, outra resposta.

Duas consequências práticas. Uma pontuação de laboratório melhora no momento em que você publica a correção; o relatório de campo leva semanas para acompanhar, porque continua entrando na média a experiência antiga. E um teste de laboratório na fibra do seu notebook diz muito pouco sobre um visitante numa conexão móvel ruim — que é exatamente quem o percentil 75 está medindo.

Use o teste de laboratório para achar o que está errado. Use os dados de campo para decidir se realmente foi resolvido.

Como conferir onde você está

Passe a página pelo PageSpeed Insights. Ele reporta dados de laboratório e de campo lado a lado para qualquer URL pública, e nomeia o elemento específico que escolheu como o seu LCP — normalmente o jeito mais rápido de descobrir que a imagem que você achava ser o problema não é a que está sendo medida.

Fazendo a parte da compressão do jeito certo

O erro mais comum aqui não é pular a compressão, é recorrer a uma ferramenta que envia suas imagens para o servidor de outra pessoa para fazer o trabalho. É mais lento, e deixa uma cópia do seu conteúdo — possivelmente ainda não publicado — em algum lugar fora do seu controle enquanto processa.

O img-compress cuida dos passos 2 e 3 da lista acima: comprimir e converter entre JPG, PNG, WebP e AVIF, inteiramente no seu próprio dispositivo, incluindo fotos HEIC de iPhone, com uma única imagem de topo terminando com a mesma facilidade que um lote inteiro de fotos de produto antes de um lançamento.

O passo 1, redimensionar, ele deliberadamente não faz: recodifica sem mudar as dimensões, porque as dimensões certas dependem de para onde a imagem vai. Isso é trabalho do seu editor de imagens ou do seu CMS. E os atributos de entrega acima são trabalho dos seus templates — nenhum compressor consegue colocá-los para você.

Como o tamanho das imagens afeta a velocidade do seu site