O argumento de venda mais comum das ferramentas de compressão é prometer números impossíveis de comprovar, como “redução de 70% no tamanho”. Este artigo não cita nenhuma estatística do setor: apresenta apenas um conjunto de resultados reais de teste, acompanhado do método de comparação completo, para que qualquer pessoa possa reproduzir.
1. Objeto do teste: não são imagens originais, e sim imagens que “outra pessoa já comprimiu”
A maioria dos testes de compressão usa imagens originais recém-saídas da câmera, condições ideais demais. Este teste se aproxima deliberadamente de um cenário real de negócios: um site que permite upload de imagens e que, no momento da ingestão, já executa uma compressão convencional — ou seja, o objeto do teste não é uma imagem bruta sem tratamento, e sim uma imagem final que já foi “comprimida uma vez”.
Tamanho da amostra: 78 pastas, totalizando 4.624 imagens (principalmente JPG), com a estrutura típica de arquivamento “uma pasta por álbum”, sem qualquer filtragem ou limpeza.
O volume total original desses arquivos no servidor: 1,41 GB.
Quanto espaço ainda é possível extrair de uma imagem que já foi processada por uma ferramenta de compressão quando ela é passada por outra? A maioria dos usuários tem a intuição de que “uma vez comprimida, já era; comprimir de novo não adianta”.
2. Grupo de controle: quanto o empacotamento em zip economiza?
Antes de executar o ImgZilla, o mesmo lote de arquivos foi empacotado em zip sem nenhuma alteração, para observar o efeito de um algoritmo de compressão genérico:
| Volume | Em relação ao original | |
|---|---|---|
| Arquivos originais após a compressão do site | 1,41 GB | — |
| Empacotados em zip | 1,41 GB | -0,2% |
Quase nenhuma mudança. O motivo não é complicado: JPEG é, por si só, um formato comprimido; os dados de imagem já passaram por codificação de entropia, e algoritmos genéricos (o zip usa DEFLATE) dificilmente conseguem comprimir ainda mais dados já comprimidos — quer a imagem original tenha ou não passado pelo site, o zip é incapaz de ajudar aqui.
3. Teste real de recompressão com o ImgZilla
Os arquivos acima foram arrastados para o ImgZilla e comprimidos no local. As 78 pastas e as 4.624 imagens tiveram os nomes de arquivo e a estrutura de diretórios totalmente preservados:
| Volume | Em relação ao original | |
|---|---|---|
| Arquivos originais após a compressão do site | 1,41 GB | — |
| Empacotados em zip | 1,41 GB | -0,2% |
| Após a recompressão com ImgZilla | 0,75 GB | -46,8% |
Sobre a compressão que o site já havia aplicado, o ImgZilla economizou mais cerca de 662 MB, reduzindo o volume quase pela metade. Todos os caminhos de pasta, nomes de arquivo e a estrutura hierárquica ficaram exatamente iguais antes e depois — são dados reais, verificáveis diretamente, e não discurso de marketing.
Isso revela um fato-chave: “ter sido comprimido no upload do site” é diferente de “usar parâmetros específicos do formato para fazer uma codificação refinada”. A maioria dos sites, ao fazer a ingestão, executa uma compressão única e conservadora (em geral apenas limitando o parâmetro de qualidade ou as dimensões), e está longe de esgotar o espaço de codificação de cada formato. O ImgZilla ajusta os parâmetros individualmente para cada formato e aplica aos JPEG uma recodificação visualmente sem perdas — no nível do pixel há de fato alteração, mas os parâmetros são configurados em uma faixa praticamente indistinguível a olho nu, permitindo continuar extraindo espaço a partir da base “já comprimida”.
É preciso esclarecer um conceito que costuma gerar confusão: “sem perdas visuais” não é igual a “sem perdas”. No sentido estrito, a ausência de perdas (pixels totalmente inalterados) só se aplica a PNG (oxipng) e SVG; JPEG, WebP, AVIF, HEIC e GIF são, por princípio, recodificações com perdas — apenas os parâmetros de compressão são controlados dentro do limiar em que a perda não é perceptível. O ImgZilla possui uma janela de comparação integrada, com divisão de tela antes/depois, zoom em tamanho real e comparação pixel a pixel, para você mesmo verificar.
4. Análise detalhada: taxa de compressão por arquivo, dimensões em pixels e tempo de tarefa
Os 46,8% de taxa de compressão geral apresentados acima são o resultado agregado das 4.624 imagens. Ao decompor no nível de cada arquivo, é possível extrair ainda mais detalhes.
A taxa de compressão não é uniforme entre as imagens
Calculando a taxa de compressão de cada imagem (bytes depois / bytes antes), os valores variam de 32,3% a 85,8%:
- Lote com a maior taxa de compressão: cerca de 765 KB comprimidos para 109 KB, taxa de 85,8% — imagens desse tipo normalmente passaram por uma compressão inicial insuficiente e ainda têm muito espaço para recodificação.
- Lote com a menor taxa de compressão: cerca de 572 KB comprimidos para 387 KB, taxa de 32,3% — imagens desse tipo já haviam sido comprimidas de forma agressiva antes, então a margem de otimização é limitada.
- A média aritmética das taxas das 4.624 imagens é 46,44%, próxima dos 46,8% calculados pelo volume total, mas não idêntica — a primeira é a média simples das taxas de cada arquivo; a segunda é “bytes totais economizados ÷ bytes totais originais”. Essa diferença mostra que arquivos com taxas altas e baixas têm pesos assimétricos no volume total; alguns arquivos grandes influenciam o resultado final de forma desproporcional.
Vale notar que a taxa de compressão foi positiva em todas as imagens; não houve nenhum caso de “já mínimo, pulado” — ou seja, nesta leva de imagens “já comprimidas pelo site”, todas conseguiram gerar espaço real com o ImgZilla.
Dimensões em pixels: nem um pixel a menos
Analisando as dimensões em pixels de todas as 4.624 imagens, os formatos mais comuns são 1600×2400 (1.756 imagens) e sua versão horizontal 2400×1600 (500 imagens); a variação vai da menor, 450×675 (cerca de 300 mil pixels), até as maiores 3000×2000 / 2000×3000 (cerca de 6 milhões de pixels).
Conferindo por amostragem as dimensões antes e depois da compressão, elas são exatamente iguais, sem nenhuma alteração:
| Arquivo (exemplo) | Dimensão original | Dimensão após compressão |
|---|---|---|
| Amostra 1 | 1600×1066 | 1600×1066 |
| Amostra 2 | 2000×3000 | 2000×3000 |
| Amostra 3 | 1416×2128 | 1416×2128 |
Essa é a outra metade da definição de “compressão no local” que costuma passar despercebida: não apenas o nome do arquivo e o caminho não mudam, como também a resolução fica intacta. O ImgZilla não redimensiona nem corta; toda a redução de volume vem exclusivamente da recodificação, sem sacrificar pixels.
Tempo da tarefa: 51min32s para 4.624 imagens, média de 0,669s por imagem
Ambiente de teste: Mac mini com chip Apple M1, 8 GB de memória unificada, imagens em um HD mecânico de NAS conectado via rede cabeada de 2,5G.
O progresso foi monitorado pelo horário da última gravação de cada imagem (ou seja, quando o ImgZilla concluiu a compressão e gravou no disco): a primeira gravação foi às 16:06:09 e a última às 16:57:41, totalizando 51min32s para todo o lote, com média de 0,669s por imagem.
Esse número é coerente com o design de “processamento serial” do produto: as imagens são comprimidas uma a uma, em sequência, em vez de serem gravadas em paralelo fora de ordem. Em termos práticos, são cerca de 90 imagens por minuto. A velocidade real depende do tamanho das imagens e do desempenho da máquina; o valor aqui é apenas o tempo real observado neste ambiente para este lote de imagens com média de ~305 KB cada, e não um benchmark genérico.
5. Por que comprimir “no local” em vez de salvar uma cópia?
Se neste teste tivéssemos usado uma ferramenta de “salvar versão comprimida”, o resultado seria: arquivo original de 1,41 GB + versão comprimida de 0,75 GB, ocupando simultaneamente 2,16 GB — ou seja, ocupando ainda mais espaço, além de gerar uma quantidade enorme de arquivos xxx-min.jpg que precisariam ser organizados manualmente e ter as referências atualizadas no banco de dados ou nas tabelas de produtos.
O ImgZilla usa a sobregravação no local: o resultado da compressão é gravado diretamente no caminho original, e os 4.624 nomes de arquivo das 78 pastas permanecem inalterados — isso é especialmente importante para sites que já gravam os caminhos das imagens em banco de dados, CDN ou CMS, pois nenhum link precisa ser alterado após a compressão. O custo é que ele modifica o arquivo original; por isso, por padrão, o arquivo original é primeiro movido para a lixeira do sistema e, em seguida, o resultado da compressão é gravado. Se você quiser desfazer, é só clicar com o botão direito na lixeira e escolher “Restaurar”.
6. Análise de benefícios: do cenário real à fatura mensal
Para quem estes dados têm valor prático
- Sites/desenvolvedores que recebem upload de imagens dos usuários: armazenamento de imagens e tráfego de CDN normalmente são cobrados por GB; reduzir o volume à metade significa cortar a conta pela metade — e a taxa de tráfego é um custo que incide a cada acesso. Quanto maior o volume de acessos, mais forte é o efeito composto. Mesmo quando o site já aplica uma compressão padrão na ingestão, este teste mostrou que “rodar mais uma etapa de compressão especificamente ajustada” ainda gera um ganho considerável.
- Servidores com pouco espaço / usuários de discos de pequena capacidade: ferramentas de limpeza costumam apagar caches e arquivos duplicados, mas depois de alguns meses o acúmulo volta; já o espaço liberado pela compressão vem do fato de os próprios arquivos em uso ficarem menores, sem efeito rebote. Com estas 78 pastas, a compressão liberou diretamente 662 MB de espaço, de forma permanente.
- Usuários que movem dados com frequência: ao copiar, sincronizar ou fazer backup, a redução de 46,8% no volume encurta o tempo de transferência na mesma proporção. Comprima uma vez e cada transferência futura será mais rápida.
Quanto valem esses 46,8% na fatura mensal?
A redução de volume só é convincente quando aparece na fatura. Abaixo não citamos estatísticas do tipo “compressão aumenta conversão”; apenas multiplicamos os 46,8% obtidos neste teste pelos preços públicos de armazenamento/tráfego dos principais provedores de nuvem, em um cálculo puramente aritmético.
Economia com armazenamento = volume economizado (GB) × preço unitário (yuan ou US$ / GB / mês)
Economia com tráfego de saída = volume economizado (GB) × downloads/acessos no mês × preço unitário (yuan ou US$ / GB)
Com o volume pela metade, as duas contas também caem pela metade — isso é matemática, não achismo.
Custo de armazenamento: quanto maior o acervo, maior o ganho
Provedores chineses:
| Tamanho original do acervo | Volume economizado | Armazenamento Standard da Alibaba Cloud OSS ¥0,09/GB/mês |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/mês |
| 100 GB | 46,8 GB | ¥4,21/mês |
| 1 TB | 479 GB | ¥43,1/mês |
Provedores internacionais:
| Tamanho original do acervo | Volume economizado | AWS S3 Standard US$0,023/GB/mês |
Google Cloud Storage US$0,020/GB/mês (Regional, EUA) |
Azure Blob Storage US$0,018/GB/mês (Hot, LRS) |
Cloudflare R2 US$0,015/GB/mês |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | US$0,11/mês | US$0,09/mês | US$0,08/mês | US$0,07/mês |
| 100 GB | 46,8 GB | US$1,08/mês | US$0,94/mês | US$0,84/mês | US$0,70/mês |
| 1 TB | 479 GB | US$11,02/mês | US$9,58/mês | US$8,62/mês | US$7,19/mês |
Os preços de armazenamento de vários provedores internacionais são muito próximos (diferenças de até 30%); o importante não é qual é mais barato, e sim que — seja qual for o escolhido — com o volume pela metade, essa conta também cai praticamente pela metade, e a cobrança é mensal. Uma única compressão passa a valer pelo novo volume em todos os meses seguintes: é um investimento único com retorno contínuo de longo prazo.
Tráfego: o verdadeiro vilão, que cresce com os acessos
O tráfego merece mais atenção que o armazenamento, porque é o produto volume × downloads — quanto mais a imagem é acessada, maior o benefício da compressão. Suponha um acervo de 100 GB que gere 500 GB de tráfego de saída pela CDN no mês (o equivalente a todo o acervo ser baixado cerca de 5 vezes):
| CDN / preço do tráfego de saída (primeira faixa) | Fatura mensal antes | Após a compressão (tráfego -46,8%) | Economia mensal | Economia anual |
|---|---|---|---|---|
| Alibaba Cloud CDN (China, faixa baixa ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront (Ásia-Pacífico, US$0,12/GB) | US$60,0 | US$31,9 | US$28,1 | US$337 |
| Google Cloud CDN (América do Norte/Europa, US$0,08/GB) | US$40,0 | US$21,3 | US$18,7 | US$224 |
| Azure Front Door Standard, Zona 1 (US$0,08/GB) | US$40,0 | US$21,3 | US$18,7 | US$224 |
Acima foram usadas as menores faixas de preço de cada provedor; na prática, os preços por faixa costumam ser mais altos (o tráfego doméstico da CDN da Alibaba Cloud pode chegar a ¥1,31/GB). Quanto maior a fatura, maior o valor absoluto economizado com a compressão. Além disso, essa faixa do Azure é atualmente o Front Door Standard; além do tráfego de saída por GB, há uma taxa de serviço básica de cerca de US$35/mês, que a compressão não reduz e que não foi incluída na economia da tabela.
Cloudflare R2 é uma exceção: o tráfego de saída custa US$0 — se o bucket usar R2, o ganho com a compressão aparece quase inteiramente no armazenamento, já que a parte de tráfego não gera fatura. Isso corresponde a uma estrutura de custos diferente da arquitetura com cobrança dupla de “armazenamento + tráfego” (como Alibaba Cloud OSS+CDN, AWS S3+CloudFront); é preciso conhecer seus próprios itens de cobrança antes de escolher o provedor.
Os preços unitários acima foram compilados das tabelas públicas de 2026 de cada plataforma. Os valores reais podem variar conforme região, desconto da conta e faixa de preço; consulte sempre o preço em tempo real no site oficial. O número de downloads e acessos é uma hipótese de exemplo; substitua pelos dados reais da sua fatura ao estimar.
7. Economia de tempo em transferência e upload
Reduzir o volume à metade reduz o tempo de transferência na mesma proporção — essa regra não depende da conta de nuvem; vale tanto na cópia e no backup locais quanto no upload dos usuários.
Cenário local: USB 3 e rede gigabit
- HD externo USB 3: a taxa sustentada de leitura/gravação costuma ficar entre 100 e 150 MB/s; adotamos a mediana de 120 MB/s.
- SSD externo USB 3: a taxa é bem mais alta, normalmente entre 400 e 500 MB/s; adotamos 450 MB/s.
- Rede cabeada gigabit (1000 Mbps): o limite teórico é 125 MB/s; depois de descontar a sobrecarga de protocolo, a taxa sustentada medida fica em torno de 100–110 MB/s; adotamos 105 MB/s.
Os valores acima são estimativas de faixas comuns observadas na prática; a velocidade real sofre influência do meio de armazenamento, da qualidade das interfaces e do ambiente de rede. Servem apenas como referência.
| Cenário | Volume economizado | HD USB 3 @120 MB/s | SSD USB 3 @450 MB/s | Rede gigabit @105 MB/s |
|---|---|---|---|---|
| Imagens deste teste | 662 MB | ≈5,5 s | ≈1,5 s | ≈6,3 s |
| Acervo de 10 GB | 4,68 GB | ≈40 s | ≈10 s | ≈45 s |
| Acervo de 100 GB | 46,8 GB | ≈6,5 min | ≈1,7 min | ≈7,4 min |
| Acervo de 1 TB | 479 GB | ≈66 min | ≈18 min | ≈76 min |
Os 662 MB deste teste podem parecer pouco quando vistos isoladamente — apenas alguns segundos. Mas, como no caso do armazenamento, é um investimento único com retorno contínuo: seja copiando para/de um HD externo, sincronizando um NAS, usando o Time Machine, migrando para um Mac novo ou enviando para um colega — enquanto esses dados continuarem sendo transferidos, cada vez você economizará tempo na mesma proporção. Comprima uma vez; a partir daí, cada transferência será mais rápida.
Se a compressão for feita antes do upload do usuário: tempo de espera economizado
Os benefícios calculados até aqui são os “depois que a imagem já está armazenada” — armazenamento, tráfego de CDN, transferência local. Há mais uma etapa que merece atenção: o tempo de espera entre o usuário apertar “Enviar” e a conclusão da barra de progresso, que depende da banda de upload do próprio usuário. E o upload costuma ser o gargalo mais lento de toda a cadeia — na maioria das bandas largas residenciais, o upload tem apenas entre um décimo e um quinto do download, e a situação é ainda pior nas redes móveis. Se o site ou o app comprimir a imagem com o ImgZilla antes do upload, o volume economizado vira diretamente menos tempo de espera.
Com base no tamanho médio das imagens deste teste: as originais já comprimidas pelo site têm em média 299 KB; após a recompressão com ImgZilla, a média é 159 KB; cada imagem economiza, em média, cerca de 140 KB.
| Largura de banda de upload (faixas típicas de testes públicos; apenas referência) | Imagem única 299 KB → 159 KB |
Upload de 50 imagens ≈15,0 MB → 8,0 MB |
Upload de todas as 4.624 imagens 1,41 GB → 0,75 GB |
|---|---|---|---|
| Rede móvel (4G/5G combinados, mediana nacional em testes públicos de ~10–50 Mbps; adotamos 30 Mbps) | economiza ≈0,04 s | economiza ≈1,9 s | economiza ≈3 min |
| Upload comum de banda larga residencial (planos de 100 Mb/1 Gb de download, upload em geral limitado entre 20 e 30 Mbps; adotamos 25 Mbps) | economiza ≈0,04 s | economiza ≈2,2 s | economiza ≈3,5 min |
| Upload simétrico gigabit (poucas operadoras/linhas empresariais, 1000 Mbps) | economiza ≈0,001 s | economiza ≈0,06 s | economiza ≈5,3 s |
| Referência internacional: upload médio da banda larga fixa dos EUA (dados Ookla, 2026) | economiza ≈0,02 s | economiza ≈1 s | economiza ≈1,5 min |
Olhar para essa tabela pensando em uma única imagem pode parecer inútil — 0,04 s é quase imperceptível, e esse é um resultado honesto: este lote de teste não era grande (já tinha sido comprimido na entrada do site, com média de apenas 299 KB por imagem). Os cenários em que o valor realmente aparece são dois: operações em lote, como enviar um álbum inteiro ou dezenas de imagens de uma só vez, e materiais originais de maior volume (como JPEGs diretos da câmera ou um primeiro upload de UGC que ainda não passou pela compressão do site, normalmente com vários MB por imagem em vez de algumas centenas de KB) — com a mesma taxa de compressão, a economia absoluta em segundos cresce na mesma proporção. Para usuários de redes móveis, que já têm upload mais lento, a redução na espera fica ainda mais perceptível.
Os valores das faixas de rede móvel e banda larga residencial têm como base estatísticas públicas de velocidade medidas no país (medianas de 4G/5G, proporções comuns de upload em banda larga). A velocidade real é bastante influenciada pela operadora, região, dispositivo e congestionamento da rede; servem apenas como referência de ordem de grandeza. Os dados de upload da banda larga fixa dos EUA vêm de relatórios relacionados ao Ookla Speedtest.
Quer validar você mesmo? Baixe o ImgZilla direto da Mac App Store e faça um teste com algumas imagens já processadas do seu próprio site antes de decidir comprimir o restante.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Saiba mais: https://imagetool.app/ImgZilla