Como salvar fotos para web sem perder qualidade visível?

Uma fotografia de 24, 40 ou 60 megapixels pode ficar excelente num site.

Isso não significa que você precise enviar todos esses pixels para o navegador.

Na maioria dos casos, preparar uma fotografia para web envolve justamente descartar informação: reduzir dimensões, aplicar compressão e, dependendo do formato, eliminar dados que estavam presentes no arquivo original.

O objetivo correto, portanto, não é como salvar fotos para web sem perder absolutamente nada.

É outro:

reduzir o arquivo até onde a perda deixa de ser visível no tamanho em que a fotografia realmente será mostrada.

Essa diferença muda completamente o processo.

Uma imagem de 6000 × 4000 pixels não fica automaticamente melhor num artigo cuja área útil mostra a foto com cerca de 1000 ou 1200 pixels de largura.

Ela pode apenas ficar mais pesada.

Do outro lado, comprimir demais uma imagem pequena pode produzir blocos, halos, perda de textura e gradações ruins que o visitante realmente percebe.

O ponto de equilíbrio não está em um número mágico de JPEG, numa regra de 72 DPI ou em declarar WebP ou AVIF vencedor.

Ele está na combinação entre:

dimensão em pixels;
tamanho real de exibição;
formato;
compressão;
conteúdo da fotografia;
maneira como o site entrega a imagem ao visitante.

Vamos separar essas coisas.

Neste artigo

Dimensão, peso e qualidade não são a mesma coisa

É comum tratar tudo como “resolução”.

Mas há três conceitos diferentes.

Dimensão

É a quantidade de pixels da imagem.

Por exemplo:

6000 × 4000 px

1600 × 1067 px.

Peso do arquivo

É o espaço ocupado pelo JPEG, WebP, AVIF ou outro arquivo:

180 KB, 700 KB, 8 MB e assim por diante.

Qualidade visual

É aquilo que você consegue perceber:

detalhe;
textura;
gradações;
nitidez;
ausência de blocos;
ausência de halos;
cor.

Uma foto pode possuir muitos pixels e estar horrivelmente comprimida.

Outra pode ter dimensões bem menores, pesar uma fração do arquivo e ainda parecer praticamente igual no site.

Esse é o primeiro conceito importante:

mais pixels não significam automaticamente mais qualidade visível.

Você pode se interessar por O que é um pixel na fotografia digital?

Descubra primeiro quanto a foto realmente aparece na página

Antes de escolher JPEG, WebP ou qualquer nível de qualidade, descubra uma coisa:

qual é a maior dimensão em que essa fotografia será realmente exibida?

Imagine um arquivo original de:

6000 × 4000 px

num site cuja coluna de conteúdo nunca ultrapassa aproximadamente:

1200 px de largura.

Enviar os 6000 pixels completos obriga o navegador ou o sistema do site a lidar com muito mais informação do que aquela necessária para a visualização comum.

O web.dev recomenda justamente servir imagens em dimensões adequadas ao espaço em que serão exibidas e utilizar imagens responsivas para evitar que dispositivos menores baixem arquivos maiores sem necessidade.

Isso não significa exportar obrigatoriamente tudo com 1200 px.

Telas de alta densidade podem aproveitar versões maiores.

É por isso que sistemas modernos podem disponibilizar mais de uma versão da mesma fotografia e deixar o navegador selecionar qual arquivo faz sentido para aquele dispositivo.

A resposta correta, portanto, não é:

“Toda foto para web deve ter 1200 px.”

É:

não envie milhares de pixels extras sem saber por que eles precisam estar lá.

Uma foto de 6000 px pode parecer igual a uma de 1600 px

Imagine que as duas sejam mostradas com 800 px de largura numa tela.

A versão de 6000 px possui muito mais informação no arquivo original.

Mas o visitante não está vendo a fotografia a 6000 px.

Ela está sendo reduzida para caber no layout.

Se a versão de 1600 px foi bem redimensionada e comprimida, a diferença visual pode ser mínima ou inexistente naquela apresentação.

Ao mesmo tempo, o arquivo menor pode:

baixar mais rapidamente;
consumir menos dados móveis;
ocupar menos espaço;
reduzir trabalho de processamento;
melhorar a experiência de carregamento.

O Google lembra que imagens costumam representar parcela importante do peso das páginas e recomenda técnicas modernas de otimização e imagens responsivas justamente para equilibrar qualidade e velocidade.

O erro é confundir arquivo original melhor com arquivo melhor para aquele destino.

E telas Retina ou de alta densidade?

Aqui a história fica um pouco mais interessante.

Uma imagem mostrada numa área de 800 pixels CSS pode se beneficiar de um arquivo com mais pixels físicos em uma tela de alta densidade.

Por isso não precisamos preparar uma única imagem extremamente pequena e obrigá-la a servir para tudo.

O HTML permite fornecer várias versões por meio de recursos como srcset e sizes. O navegador pode escolher uma versão adequada à largura disponível e às características do dispositivo.

Para quem publica em WordPress, boa parte dessa infraestrutura já pode acontecer automaticamente.

Desde versões antigas, o WordPress cria diferentes tamanhos das imagens enviadas e incorpora suporte a imagens responsivas com srcset e sizes.

Ou seja:

você não precisa resolver todo dispositivo criando manualmente uma única imagem gigantesca.

72 DPI para web é um mito

Esta é uma das regras mais repetidas da fotografia digital:

“Para internet, salve em 72 DPI.”

Não é assim que o navegador decide a qualidade ou o tamanho da fotografia.

Para uma imagem exibida na web, o que interessa diretamente é sua dimensão em pixels e o tamanho definido pelo layout.

Considere duas cópias da mesma fotografia:

1200 × 800 px a 72 PPI

1200 × 800 px a 300 PPI.

Se você apenas altera o valor de PPI sem reamostrar a imagem, as duas continuam tendo exatamente:

1200 × 800 pixels.

O navegador não ganha novos detalhes na segunda e não precisa reduzir a primeira por ela estar marcada como 72.

A própria documentação e discussão técnica da Adobe são claras: para gráficos exibidos na web, as dimensões em pixels importam; a informação de PPI/DPI é essencialmente uma referência relevante para tamanho de impressão, não uma regra de exibição no navegador.

Portanto, não faça isto:

“Vou mudar de 300 para 72 DPI para deixar a foto leve.”

Se você não alterou a quantidade de pixels ou a compressão, não realizou a otimização que imagina.

O que você deveria verificar é:

quantos pixels a imagem possui e quantos realmente precisa possuir.

DPI e PPI também não são exatamente a mesma coisa

Outro detalhe ajuda a evitar confusão.

PPI significa pixels por polegada e descreve uma relação entre pixels e tamanho físico.

DPI é tradicionalmente associado a pontos de impressão.

Os termos são frequentemente misturados em programas e tutoriais, mas nenhum deles substitui a dimensão em pixels quando estamos falando do arquivo que será exibido numa página.

Se seu site pede uma imagem de 1600 × 900 px, é essa informação que precisa comandar o redimensionamento.

Não “72 DPI”.

JPEG ainda é perfeitamente válido

Com tantos formatos modernos, parece que utilizar JPEG se tornou um erro.

Não se tornou.

JPEG continua sendo uma escolha extremamente prática para fotografia:

possui compatibilidade ampla;
é fácil de produzir;
comprime fotografias muito bem;
é aceito praticamente em qualquer fluxo.

Sua principal característica é utilizar compressão com perdas.

Quanto mais você comprime, mais informação é descartada.

Isso é ruim se levado longe demais.

Mas o fato de uma compressão ser “com perdas” não significa que a perda seja necessariamente perceptível no resultado final.

Essa distinção é importante.

Perda matemática não é automaticamente perda visual relevante.

Uma fotografia pode ter descartado informação e continuar parecendo excelente no tamanho em que será apresentada.

WebP pode reduzir bastante o arquivo

WebP foi desenvolvido especificamente com uso na web em mente e suporta compressão com e sem perdas, além de transparência.

Segundo a documentação do Google, WebP com perdas pode produzir arquivos substancialmente menores que JPEG em condições comparáveis, enquanto o modo sem perdas também pode reduzir significativamente o tamanho em relação a PNG.

Para fotografia em sites modernos, é uma opção muito forte.

Mas isso não significa:

WebP sempre vence JPEG.

Imagine:

JPEG bem dimensionado com 180 KB

contra

WebP de uma fotografia enviada com dimensões absurdamente maiores que o necessário e pesando 900 KB.

O primeiro pode ser a opção melhor para a página.

O formato não salva um fluxo ruim.

E o AVIF?

AVIF é outra alternativa moderna, com compressão bastante eficiente e suporte atual amplo.

O MDN o classifica entre os formatos modernos adequados à web, e o Google já indexa AVIF normalmente na Pesquisa e no Google Imagens.

Hoje, portanto, não faz sentido escrever um guia de imagens para web que considere apenas:

JPEG, PNG e WebP.

AVIF precisa estar na conversa.

Mas novamente não há necessidade de transformar a escolha em guerra de formatos.

Tipo de imagem	Formato que merece ser considerado
Fotografia com máxima simplicidade e compatibilidade	JPEG
Fotografia buscando boa eficiência e fluxo moderno	WebP
Fotografia buscando compressão moderna ainda mais eficiente	AVIF
Imagem que exige transparência	PNG, WebP ou AVIF, conforme o fluxo
Logotipo ou arte vetorial	SVG quando apropriado

A Pesquisa Google atualmente aceita JPEG, PNG, WebP, SVG e AVIF, entre outros formatos.

Portanto, SEO não exige que uma fotografia continue em JPEG apenas por tradição.

PNG raramente é a melhor escolha para uma fotografia comum

PNG possui compressão sem perdas e é excelente em determinadas aplicações.

Por exemplo:

elementos gráficos;
transparência;
capturas de interface;
algumas ilustrações;
imagens em que bordas extremamente definidas são importantes.

Mas uma fotografia complexa em PNG pode resultar num arquivo muito maior que uma versão visualmente equivalente em JPEG, WebP ou AVIF.

Então:

“sem perdas” não significa automaticamente “melhor para web”.

Se o visitante precisa baixar cinco vezes mais dados e não percebe qualquer diferença prática, preservar cada bit não trouxe benefício para aquele uso.

Não existe uma “qualidade 80” universal

Outra receita frequente é:

“Exporte JPEG em qualidade 80.”

Pode ser um bom ponto de partida.

Não deveria ser tratado como lei.

Escalas de qualidade não são necessariamente equivalentes entre programas e codificadores.

Além disso, fotografias diferentes reagem de maneiras diferentes à compressão.

Uma imagem pode possuir:

céu com gradação suave;
cabelo;
folhas;
grama;
textura de tecido;
ruído de alta frequência;
áreas completamente lisas.

Esses conteúdos não se degradam visualmente do mesmo modo.

A melhor estratégia é mais simples:

pare de escolher a compressão pelo número e comece a escolher pela imagem resultante.

Faça três versões e compare

Um método muito mais confiável é exportar algumas variantes.

Por exemplo:

uma versão de qualidade alta;
uma intermediária;
uma mais comprimida.

Depois compare.

Observe principalmente:

bordas;
cabelo;
folhas;
texturas finas;
céu;
sombras suaves;
contornos com contraste;
áreas de cor uniforme.

Quando começar a perceber:

blocos, halos, manchas, gradações quebradas ou textura artificial, você provavelmente passou do ponto para aquele uso.

Depois volte uma etapa.

A menor versão que continua visualmente adequada no destino final é uma ótima candidata.

Compare também no tamanho em que a pessoa verá a fotografia

Há um detalhe importante.

Se você sempre analisa sua foto ampliada a 400%, encontrará defeitos que talvez jamais sejam perceptíveis no site.

Isso pode fazer você manter arquivos muito maiores apenas para preservar informação invisível durante o uso real.

Por outro lado, analisar apenas uma miniatura pode esconder compressão excessiva.

Faça as duas avaliações:

Em 100%

para identificar artefatos e problemas de processamento.

No tamanho real do site

para descobrir se esses problemas realmente sobrevivem à apresentação final.

O objetivo é qualidade perceptível, não perfeição microscópica sem consequência.

Redimensionar também pode alterar a nitidez

Quando uma imagem cai de 6000 para 1600 pixels de largura, vários pixels originais precisam ser convertidos numa representação menor.

Esse processo pode alterar a percepção de detalhes e microcontraste.

Uma foto que estava perfeitamente nítida no arquivo original pode parecer ligeiramente mais suave depois de uma redução forte.

A própria documentação do WordPress observa que o redimensionamento pode alterar a percepção de nitidez e que uma pequena correção de sharpening pode ser apropriada após a redução.

Por isso, um fluxo fotográfico mais coerente é:

terminar a edição principal;
redimensionar para o tamanho de saída;
avaliar a nitidez novamente;
aplicar nitidez de saída se realmente necessário;
fazer a compressão final.

Não aplique sharpening agressivo apenas porque a imagem vai para a internet.

Excesso de nitidez também produz halos e pode piorar depois da compressão.

Se a foto ficou “lavada”, talvez compressão não seja o problema

Outra situação comum:

a fotografia parece correta no editor, mas depois do upload as cores parecem diferentes.

A primeira suspeita costuma ser:

“o site comprimiu demais.”

Nem sempre.

Pode haver um problema de gerenciamento de cor.

Para conteúdo destinado exclusivamente à visualização ampla na web, a Adobe continua recomendando sRGB como escolha segura e previsível, justamente porque a fotografia será vista em uma enorme variedade de telas e ambientes.

Isso não significa que espaços de cor mais amplos sejam inúteis.

Significa que seu fluxo precisa saber onde eles serão corretamente interpretados.

Se previsibilidade é a prioridade, exportar para sRGB continua sendo uma solução simples.

Incorporar ou remover metadados?

Metadados também ocupam espaço.

Informações EXIF podem incluir:

modelo da câmera;
lente;
exposição;
data;
localização;
outros dados técnicos.

Alguns exportadores permitem retirar tudo para reduzir o arquivo.

Só que remover indiscriminadamente metadados também pode eliminar informações de autoria e copyright que você desejava preservar.

A melhor lógica não é:

“sempre remova metadata.”

É:

mantenha aquilo que possui função e remova aquilo que não precisa ser publicado.

Localização GPS, por exemplo, pode ser uma informação que você deliberadamente não quer distribuir.

Crédito e copyright podem ter outro valor.

Esse ponto conversa diretamente com proteção e rastreabilidade de fotografias na internet.

Você pode se interessar também por Como proteger suas fotos na internet: o que realmente funciona contra cópia e uso indevido?

O arquivo que você envia ao WordPress pode não ser o arquivo que o visitante recebe

Esse é um detalhe importante para quem administra um site.

Você exporta:

foto.jpg

e envia ao WordPress.

Isso não significa necessariamente que cada visitante baixará exatamente aquele mesmo arquivo.

O WordPress cria diferentes tamanhos das imagens enviadas e oferece suporte nativo a imagens responsivas. Dependendo do tema, plugins, CDN e configuração, o navegador pode receber uma versão dimensionada para aquele espaço.

Na geração WordPress 7.1, o processamento de mídia evoluiu ainda mais, incluindo processamento no navegador para tarefas como redimensionamento, compressão, conversão de formato e geração de tamanhos derivados em ambientes compatíveis.

A consequência é importante:

otimização de imagem possui duas etapas.

A primeira é o arquivo que você prepara.

A segunda é o arquivo que o site realmente entrega.

Se você quer diagnosticar uma página lenta ou uma fotografia visivelmente degradada, precisa descobrir em qual dessas etapas está o problema.

Confira também Apps grátis para editar fotos: qual vale instalar e quando o editor do celular já basta

Não confie apenas no arquivo da Biblioteca de Mídia

Se você enviou um JPEG de 2 MB e a página carrega rapidamente, talvez o visitante não esteja recebendo exatamente aquele JPEG original.

Da mesma maneira, se você enviou uma fotografia excelente e ela aparece ruim, algum processamento posterior pode ter gerado outra versão.

Para verificar, você pode inspecionar a imagem efetivamente carregada pelo navegador e observar:

URL do arquivo;
formato;
dimensões;
peso transferido;
versão escolhida pelo srcset.

Isso separa percepção de diagnóstico.

Sem essa verificação, você pode ficar recomprimindo o original sem resolver o verdadeiro problema.

Desktop e celular não precisam receber a mesma imagem

Imagine uma foto de capa que aparece:

1400 px de largura num desktop

400 px num celular.

Obrigar o telefone a baixar exatamente o mesmo arquivo enorme do desktop pode desperdiçar dados.

É justamente para isso que existem imagens responsivas.

O navegador recebe opções e escolhe a mais adequada de acordo com as condições e o tamanho de apresentação.

Isso é muito melhor do que produzir uma imagem tão pequena que fique ruim no desktop ou uma tão grande que desperdice tráfego no celular.

Lazy loading não é configuração de exportação

Outro erro comum é misturar duas coisas.

Compressão e redimensionamento tratam do arquivo.

Lazy loading trata do momento em que esse arquivo será solicitado pelo navegador.

Lazy loading pode ser excelente para imagens que aparecem mais abaixo numa página longa.

O navegador pode adiar o download até que elas estejam próximas de serem necessárias.

Mas isso não significa que todas as imagens devam receber lazy loading.

A imagem principal pode ficar mais lenta com lazy loading

Se uma grande imagem está visível imediatamente ao abrir a página e participa do Largest Contentful Paint, atrasar sua solicitação pode piorar justamente a percepção de velocidade.

O web.dev recomenda que imagens visíveis na primeira tela, especialmente candidatas a LCP, não sejam carregadas com loading="lazy"; o lazy loading deve ser reservado principalmente às imagens que começam fora da viewport.

Portanto, a regra:

“ative lazy loading em todas as fotos”

também é simplificação demais.

A pergunta correta é:

quando esta imagem precisa chegar?

Então qual largura devo usar?

Não existe número universal.

Mas existe um processo.

Se a área máxima do seu artigo possui aproximadamente 1200 px, uma imagem destinada exclusivamente àquela coluna não precisa automaticamente ter 6000 px.

Você pode preparar uma versão coerente com o uso e deixar o sistema responsivo lidar com diferentes dispositivos.

Se a fotografia também terá:

abertura em tela cheia;
zoom;
download;
venda;
inspeção detalhada;

a necessidade muda.

O tamanho deve nascer da função.

Não de uma regra genérica de internet.

E quanto o arquivo deve pesar?

Também não existe um limite capaz de servir para todas as fotografias.

Um retrato relativamente simples pode comprimir muito bem.

Uma floresta cheia de folhas e detalhes pode exigir mais dados.

Uma grande imagem de destaque merece outro orçamento que uma pequena imagem dentro do texto.

A pergunta útil é:

o próximo aumento de peso ainda produz uma melhora que consigo enxergar?

Imagine duas exportações:

240 KB

620 KB.

Se você não consegue distinguir as duas no tamanho em que serão exibidas, os 380 KB adicionais possuem pouca justificativa.

Agora compare:

80 KB

240 KB.

Se a de 80 KB mostra blocos e destrói cabelo e textura, aí o arquivo menor passou do ponto.

Essa comparação é muito mais útil que um limite fixo para toda imagem.

Um fluxo simples para exportar uma fotografia para web

Comece pela imagem finalizada em resolução alta.

Depois:

Descubra o tamanho de exibição.
Não comece pelo formato.
Redimensione para uma dimensão coerente.
Considere também telas de alta densidade e o sistema responsivo do site.
Converta a cor para um fluxo previsível.
Para uso web geral, sRGB continua sendo uma opção segura.
Avalie a nitidez depois do redimensionamento.
Corrija apenas se necessário.
Escolha o formato.
JPEG, WebP e AVIF podem todos fazer sentido para fotografia.
Ajuste a compressão olhando a imagem.
Não aceite um número de qualidade como regra universal.
Compare o peso.
Descubra quanto está pagando em bytes pela melhora visual.
Faça o upload e verifique o arquivo realmente servido.
Especialmente em WordPress, CDN ou sistemas de otimização automática.

Esse processo funciona melhor que decorar:

72 DPI + JPEG qualidade 80 + 1920 px.

Checklist antes de publicar

Antes de enviar uma fotografia para um site, confira:

a largura máxima em que ela será realmente exibida;
se há pixels excessivos sem função;
se JPEG, WebP ou AVIF combina melhor com o fluxo;
se a compressão já começou a produzir artefatos;
se a nitidez continua adequada depois do redimensionamento;
se o perfil de cor está coerente com o destino;
se metadados privados, como GPS, precisam ser removidos;
se dados de autoria que você deseja preservar continuam presentes;
se o WordPress ou CDN está criando outras versões;
se a imagem principal está sendo carregada com prioridade adequada.

Essa lista é muito mais útil que procurar uma configuração universal de exportação.

A melhor imagem para web não é a menor possível

Também não é a maior.

É a versão que entrega informação visual suficiente para aquele uso com o menor custo razoável de transferência.

Às vezes isso será JPEG.

Às vezes WebP.

Às vezes AVIF.

Às vezes 1200 px serão suficientes.

Em outra página, 2400 px podem fazer sentido.

E 72 ou 300 PPI provavelmente nem entram na decisão.

O teste final é simples:

retire informação até o momento imediatamente anterior em que você começa a sentir falta dela.

Se uma fotografia ficou três vezes menor e continua parecendo igual no tamanho real do site, você não destruiu a imagem.

Você eliminou dados que o leitor provavelmente nunca veria.Essa é a diferença entre apenas comprimir uma fotografia e realmente otimizá-la para a web.