Porque é que a compressão de imagens importa
Publicado em 17 de agosto de 2026 · 5 min de leitura

O seu telemóvel acabou de gravar uma fotografia com 4 a 8 megabytes. É um tamanho razoável para arquivar o original — um sensor de 12 megapíxeis, processamento HDR e um JPEG que quase não deitou nada fora. É um tamanho péssimo para quase tudo o que vai fazer com essa fotografia a seguir.
Um hero de blog, um cartão de produto, um envio no WhatsApp, um formulário de candidatura, um e-mail a um cliente: a maior parte desses destinos fica satisfeita com 100 a 400 KB. Os megabytes a mais não fazem a imagem parecer melhor no ecrã. Tornam a página mais lenta, falham o envio, magoam o plano de dados e incham a fatura das cópias de segurança. Esse desfasamento — o original versus o que o destino realmente precisa — é a razão pela qual a compressão de imagens importa antes de carregar o que quer que seja.
Os sites pagam por cada megabyte que não usa
Na web, as imagens são normalmente o elemento mais pesado da página. O Largest Contentful Paint (LCP) — o Core Web Vital que mede quando o visual principal aparece de facto — resume-se muitas vezes a «quanto tempo demorou essa imagem hero a descarregar?». Um JPEG de 3 MB numa ligação 4G pode ficar ali durante segundos. Um WebP de 200 KB do mesmo recorte aparece num piscar de olhos.
Um LCP lento não é uma pontuação abstrata. A taxa de rejeição sobe quando o primeiro ecrã parece preso. As conversões caem quando a fotografia do produto continua a girar. O posicionamento na pesquisa sofre porque o Google usa esses vitais como sinal de ranking. Comprimir antes de publicar é uma das vitórias de velocidade mais baratas que pode comprar: não está a reescrever o site, está a enviar menos bytes.
Se o destino é a página, o trabalho é concreto — redimensionar à largura apresentada, escolher um formato moderno, definir uma qualidade que continue nítida. Esse pipeline está emcomo reduzir o tamanho das imagens para um site mais rápido. O «porquê» por baixo é simples: um carregamento sem compressão é um imposto que cada visitante paga, em cada carregamento, para sempre.
O e-mail, o chat e os carregamentos vão rejeitar o original
O e-mail de consumo ainda limita os anexos a cerca de 20–25 MB para a mensagem inteira. Cinco fotografias de telemóvel a 6 MB cada uma rebentam esse tecto antes de acrescentar um PDF. O envio falha, ou o cliente nunca recebe as imagens, ou o Gmail transforma-as em silêncio num link do Drive que alguns destinatários não conseguem abrir. Comprimir primeiro é a diferença entre «aqui estão as fotografias» e um fio de seguimento sobre o tamanho do ficheiro.
As aplicações de chat são mais rigorosas de outra forma. O WhatsApp, o iMessage e a maior parte dos mensageiros de trabalho voltam a comprimir o que envia — muitas vezes para um JPEG pequeno com artefactos visíveis — porque assumem que você não o fez. Perde o controlo da qualidade e mesmo assim gasta a largura de banda de carregamento do original. Um ficheiro de 250 KB que tenha comprimido você próprio costuma sobreviver à segunda passagem mais próximo do que pretendia.
Os formulários são a versão pouco glamurosa do mesmo problema. Portais universitários, sites de vistos, sinistros de seguros e plataformas de emprego publicam limites rígidos: «JPG ou PNG, máximo 500 KB». Uma fotografia de telemóvel sem compressão falha a validação. As pessoas fazem então uma captura de ecrã, reduzem no Preview até ficar lamacenta, ou desistem. Uma passagem de compressão a sério deixa-o abaixo do tecto sem transformar uma foto de passaporte num borrão.
Os mesmos ficheiros também carregam uma escolha que deve fazer de propósito:compressão com perdas vs sem perdas. As fotografias toleram uma codificação com perdas; as capturas de ecrã, os logótipos e os documentos com texto muitas vezes não. A compressão não é um único cursor — é combinar o método com o ficheiro.
Os dados móveis e as ligações lentas são a norma, não a exceção
Uma imagem de 5 MB numa ligação tarifada não é um inconveniente menor. É uma fatia visível do limite diário de dados, um engarrafamento no metro cheio, um timeout no Wi-Fi do hotel. Pessoas com planos móveis caros, banda larga rural e dispositivos antigos não são um nicho — são uma fatia grande de cada site público e de cada conversa de grupo.
A acessibilidade faz parte do mesmo quadro. Uma página que não consegue acabar de carregar as imagens é uma página que algumas pessoas não conseguem usar. A compressão não substitui o texto alternativo nem o contraste, mas é uma das poucas decisões de desempenho que decide se o conteúdo chega de todo. Servir 200 KB em vez de 5 MB é a diferença entre «isto funciona num telemóvel» e «isto funciona num telemóvel com um bom plano numa cidade».
O armazenamento e as cópias de segurança acumulam-se em silêncio
Uma fotografia sem compressão é irritante. Mil delas enchem um escalão do iCloud ou do Google Fotos. Os rolos da câmara, as galerias de clientes e as pastas de «devíamos guardar os originais» enchem discos e quotas na nuvem com píxeis que ninguém vai alguma vez ver à resolução nativa. As cópias de segurança copiam depois esses megabytes uma segunda e uma terceira vez.
O custo não é só dinheiro. Os trabalhos de sincronização demoram mais. As pastas partilhadas emperram. Um fotógrafo que entrega 400 ficheiros prontos para a web como JPEG de 6 MB está a pedir ao destinatário que descarregue 2,4 GB de um conjunto que poderia ter sido 80 MB. Nessa escala, comprimir um ficheiro de cada vez é a ferramenta errada —a compressão em lote com descarregamento ZIPé como se mantém a galeria útil em vez de cara.
O que as imagens sem compressão custam realmente
Números aproximados e típicos — não um teste de laboratório, apenas a aritmética que a maior parte das pessoas nunca faz antes de carregar em Enviar:
| Utilização | Sem compressão | Após comprimir | O que evita |
|---|---|---|---|
| Foto de telemóvel num blog | JPEG de 4–8 MB | WebP de 150–300 KB | Segundos de LCP, largura de banda desperdiçada |
| Cinco fotos num único e-mail | ~30 MB | ~1,5 MB | Rejeição por limite de anexos |
| Carregamento num portal (teto 500 KB) | Rejeitado | Cabe, continua legível | Formulário falhado, captura lamacenta como atalho |
| Galeria de cliente com 400 imagens | ~2,4 GB | ~80 MB | Quota, tempo de sincronização, dor a descarregar |
A escolha de formato também mexe nestes números. Um PNG de uma fotografia é muitas vezes várias vezes maior do que um JPEG da mesma cena; o WebP e o AVIF costumam ficar abaixo de ambos nas fotos. Se não tem a certeza de qual o formato que pertence à página, comece porJPG vs PNG vs WebP vs AVIFem vez de comprimir o original errado.
O que fazer a seguir
Não precisa de mais uma palestra sobre fluxos de trabalho. Precisa de o ficheiro corresponder ao destino antes de sair do seu computador. Para as definições que preservam a qualidade e a sequência curta que o leva até lá, usecomo comprimir imagens sem perder qualidade. Para a codificação em si, largue o ficheiro nocompressor de imagens— corre no seu navegador, nada é enviado, e algumas centenas de kilobytes costumam chegar.