Como comprimir imagens para um site sem arruinar a qualidade

A resposta prática

Para comprimir imagens de site sem arruinar a qualidade, não comece arrastando o controle de qualidade para o número mais baixo que ainda parece aceitável. Comece pela função real da imagem na página. Um hero, uma foto de produto para zoom, uma ilustração de blog, um avatar, uma captura de tela e uma textura de fundo pedem dimensões, formatos e níveis de qualidade diferentes.

A regra útil é: redimensione primeiro para o maior tamanho realmente exibido, depois comprima só o necessário para a imagem continuar igual no layout. Se uma imagem de blog aparece com 760 pixels CSS de largura, uma fonte de 1500–1600 px costuma ser suficiente para telas de alta densidade. Um original de câmera de 5000 px é dado desperdiçado. Um export de 760 px pode ficar mole em telas retina. O arquivo certo está entre esses extremos.

«Sem perder qualidade» também precisa de uma definição simples. Em trabalho web, geralmente significa sem perda visível no tamanho em que os visitantes de fato veem a imagem, não perfeição matemática pixel a pixel. Um WebP comprimido não é idêntico ao arquivo original, mas pode ser visualmente indistinguível na página.

Antes de mais nada, decida que tipo de imagem é essa

Antes de escolher WebP, AVIF, JPEG, PNG ou um valor de qualidade, classifique o arquivo:

A tabela é propositalmente opinativa. A maior parte da compressão web mal feita vem de tratar todos os arquivos do mesmo jeito. Um hero de home pode afetar o Largest Contentful Paint. Uma imagem de detalhe de produto pode afetar confiança e conversão. Um fundo decorativo pode ser muito mais leve, porque ninguém para para analisar.

Redimensione primeiro: dimensões fazem o grosso do trabalho

A compressão reduz o número de bytes usados para guardar uma grade de pixels fixa. O redimensionamento muda a própria grade. Se a fonte tem muito mais pixels do que a página pode exibir, redimensionar é a vitória mais limpa.

Fórmula simples de dimensionamento:

largura de fonte alvo = maior largura CSS exibida × device pixel ratio

Por exemplo:

• Uma imagem de card exibida a 320 CSS px deve ter uma fonte de 640 px para telas 2x.
• Uma imagem de blog exibida a 760 CSS px deve ter uma fonte de 1500–1600 px.
• Um hero de largura completa perto de 1200 CSS px pode pedir uma fonte de 2000–2400 px, dependendo do corte e do público.

Não use 3x cegamente em tudo. O web.dev lembra que DPR e layout contam juntos e que, em muitos casos, os usuários não percebem o benefício de fontes com DPR muito alto. Um hero de 2400 px pode fazer sentido. Um hero de 5000 px «só por segurança» costuma só queimar banda.

O PhotoTools separa essas duas tarefas. Use Resize quando precisar de pixels exatos ou de um lado maior menor. Depois, em Compress, escolha JPEG, WebP ou AVIF e ajuste a qualidade.

Escolha o formato antes de mexer na qualidade

O formato decide que tipo de detalhe pode ser removido de forma limpa.

• Use WebP na maioria das fotos web. É bem suportado em navegadores modernos e costuma gerar arquivos menores que JPEG a qualidade visível equivalente. A documentação de WebP do Google indica ganhos de 25–34 % em relação a JPEGs equivalentes.
• Use AVIF onde cada byte importa. AVIF pode superar WebP em arquivos fotográficos grandes, mas é mais lento de codificar e adiciona complexidade à pipeline. Sirva com fallback, não sozinho.
• Use JPEG como fallback de compatibilidade. Continua útil para e-mail, fluxos de CMS antigos, downloads e como fonte de fallback em <img>.
• Use PNG ou WebP lossless para capturas e texto. JPEG/WebP com perda pode borrar textos pequenos de UI e criar ruído de cor nas bordas duras.
• Use SVG para logos e ícones. Um logo raster em WebP pode ser mais leve que PNG, mas um SVG bem feito costuma ser mais nítido e mais leve.

Se usar <picture>, coloque o formato mais eficiente primeiro e mantenha um fallback compatível no img aninhado:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="Cozinha reformada com armários em nogueira e luz natural"
  />
</picture>

O elemento img continua importando. É ele que carrega a fonte de fallback, alt, width e height. Não esconda informação de acessibilidade ou de layout dentro dos elementos source.

Ajustes de qualidade que funcionam na prática

Os números de qualidade não são padronizados. Qualidade 80 no JPEG de um encoder não corresponde necessariamente a qualidade 80 em outro. WebP 80, JPEG 80 e AVIF 50 também não são equivalentes. Trate a qualidade como ponto de partida e depois inspecione o arquivo exportado.

Uma cilada comum é exportar tudo em qualidade 95 ou 100 porque «parece mais seguro». Na maioria das fotos web, os bytes a mais aparecem no waterfall de rede, não na página. Outra cilada é forçar a qualidade abaixo de 50 para bater um alvo arbitrário. Se a qualidade precisa cair tanto, redimensione ou troque de formato antes de degradar mais.

Alvos de tamanho por papel na página

Não são regras do Google nem limiares mágicos de ranqueamento. São alvos práticos de revisão que ajudam a pegar imagens claramente pesadas demais.

Se uma imagem de blog de 760 px pesa 900 KB, provavelmente precisa de atenção. Se uma imagem de portfólio em largura total pesa 410 KB e está ótima, forçá-la para 90 KB pode ser o objetivo errado.

Comprimir imagens LCP e hero

A imagem que mais vale a pena otimizar costuma ser a maior acima da dobra. Na linguagem dos Core Web Vitals, geralmente é a imagem do Largest Contentful Paint. Comprimi-la ajuda — mas só se ela também for descoberta e carregada cedo.

Para um hero:

1. Corte no aspect ratio real usado na página.
2. Exporte larguras responsivas, por exemplo 1200 px e 2000 px.
3. Use AVIF primeiro e WebP/JPEG como fallback, se sua stack suporta.
4. Não aplique lazy-load no hero nem em outro candidato a LCP acima da dobra.
5. Adicione width e height para que o navegador reserve espaço de layout.
6. Use fetchpriority="high" só na única imagem que provavelmente será o elemento LCP.

Exemplo de img de fallback:

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="Cozinha reformada com armários em nogueira e luz natural"
/>

Não coloque fetchpriority="high" em uma galeria inteira. Hints de prioridade são ferramentas afiadas: reserve um para a imagem que realmente precisa chegar primeiro.

Como comparar os resultados de compressão

A comparação certa não é «arquivo original vs. arquivo comprimido em zoom de 100 %». É assim que a gente se convence a publicar imagens grandes demais. Compare no tamanho e no contexto em que os visitantes veem a imagem.

Use este passo de revisão:

1. Coloque a imagem comprimida na página real ou num layout de teste com a mesma largura.
2. Veja em larguras de desktop e de mobile.
3. Cheque as zonas de risco: rostos, pele, céu, gradientes, tecido, rótulos de produto, textos pequenos e bordas de alto contraste.
4. Alterne entre original e comprimida no tamanho renderizado.
5. Dê um zoom rápido em 100 % só para pegar artefatos óbvios, não para exigir uma perfeição que ninguém vai ver.

Os artefatos de compressão têm personalidade. JPEG costuma mostrar bordas em bloco, ringing ou ruído de cor. WebP comprimido demais pode «espalhar» a textura. AVIF, quando forçado, pode gerar banding ou aparência plastificada. Capturas em PNG geralmente falham no sentido oposto: parecem perfeitas mas pesam bem mais do que precisam.

Um fluxo com o PhotoTools para imagens de site

O PhotoTools é útil antes de a imagem chegar ao seu CMS, CDN ou repositório. Não substitui uma pipeline de build completa, mas oferece um fluxo manual limpo para sites pequenos, posts de blog, previews para cliente e arquivos avulsos.

1. Deixe o arquivo-fonte original intocado.
2. Decida o papel da imagem: hero, imagem de conteúdo, foto de produto, captura, miniatura ou fundo.
3. Use Resize primeiro quando o original for muito maior que o tamanho de exibição.
4. Abra o Compress, escolha JPEG, WebP ou AVIF e comece perto de qualidade 80 para WebP/JPEG.
5. Clique em «Compress all» e leia em cada card o tamanho original, o tamanho de saída e a porcentagem economizada.
6. Baixe o resultado e inspecione no contexto da página.
7. Se não convencer visualmente, volte ao original ou à cópia redimensionada e exporte de novo em qualidade mais alta.
8. Se ainda estiver pesado demais, reduza dimensões antes de descer a qualidade para a zona de artefatos.

Não fique recomprimindo o download já comprimido — isso empilha artefatos com perda. Volte ao master ou ao intermediário redimensionado limpo.

Metadados e privacidade

Arquivos de câmera costumam trazer metadados EXIF: coordenadas GPS, data da captura, modelo da câmera, lente e software de edição. Esses metadados não ajudam o visitante a ver a imagem. Também podem expor informações privadas.

O PhotoTools comprime as imagens decodificando o arquivo, desenhando os pixels em um canvas do navegador e exportando um novo arquivo. A MDN documenta que OffscreenCanvas.convertToBlob() pode indicar tipo de imagem e qualidade nos formatos com compressão com perda. Como a saída é gerada a partir dos pixels do canvas, os metadados de câmera geralmente não são copiados para o novo arquivo.

Para fotos sensíveis, confira o download final com um leitor de metadados antes de publicar. Privacidade não é só tamanho de arquivo.

Erros comuns que fazem imagens ficarem ruins

• Comprimir antes de redimensionar: você tenta economizar bytes de pixels que o layout nunca vai mostrar.
• Usar PNG para fotos: em imagens de câmera, PNG costuma ficar enorme.
• Usar JPEG em capturas com texto: o arquivo pode ser menor, mas o texto fica embaralhado.
• Julgar no tamanho errado: zoom em resolução plena faz artefatos inofensivos parecerem dramáticos.
• Um único hero gigante para todos os dispositivos: usuários mobile baixam pixels de desktop que não vão usar.
• Aplicar lazy-load no hero: imagens abaixo da dobra podem ir com lazy-load; a LCP não.
• Sem width e height: a página pode «pular» enquanto as imagens carregam.
• Recomprimir o arquivo já publicado: volte à fonte sempre que puder.

Um checklist compacto de publicação

Antes de subir uma imagem de site, passe por este roteiro:

1. É o formato certo para o tipo de conteúdo?
2. A largura da fonte é baseada na largura real de exibição e num DPR plausível?
3. Existe um candidato mobile menor se o corte do hero muda no celular?
4. A qualidade está alta o bastante para rostos, rótulos, gradientes e detalhe de produto?
5. O tamanho é razoável para o papel dela?
6. A página tem width, height, um alt útil e srcset/sizes responsivos quando precisa?
7. A imagem LCP está em eager e priorizada, enquanto as abaixo da dobra vão em lazy-load?
8. Você conferiu a imagem exportada dentro do layout real?
9. Você guardou o arquivo original?

O melhor fluxo de compressão é chato no bom sentido: escolher os pixels certos, escolher o formato certo, exportar em qualidade sensata, inspecionar na página real e parar antes de a imagem começar a parecer «tratada».

Fontes técnicas consultadas

Este artigo foi revisto em relação à implementação atual de compressão e redimensionamento do PhotoTools, ao guia de performance de imagens do web.dev, ao insight «Improve image delivery» do Chrome, à ficha «Properly size images» do Chrome, à documentação da MDN sobre OffscreenCanvas.convertToBlob(), ao guia de tipos de arquivo de imagem da MDN e à documentação de WebP do Google.