No artigo anterior, o teste foi com imagens finalizadas que já haviam sido comprimidas uma vez pelo site, e o ImgZilla economizou mais 46,8%. Desta vez, vamos ao outro extremo: imagens originais direto da câmera e do celular, nunca processadas por nenhuma ferramenta. Mais uma vez, sem citar estatísticas do setor, apresentamos apenas o resultado de um teste real, com o método de comparação.
1. O objeto deste teste: as verdadeiras “imagens originais”
A amostra do artigo anterior tinha uma condição: aquelas imagens haviam passado por uma rodada de compressão no momento em que foram adicionadas ao site, portanto já não eram “cruas”. Desta vez, removemos essa condição e testamos JPEGs exportados diretamente da câmera/celular, sem nenhuma ferramenta de compressão, sem “salvar como” e sem recodificação.
Tamanho da amostra: 32188 JPEGs, arquivados em 16 buckets (subdiretórios), sem seleção ou limpeza feita para o teste.
O volume total desse lote era de 99,9 GB (cerca de 93 GiB).
As especificações também são bem típicas — todas estão na resolução padrão de saída de câmeras/celulares:
| Resolução | Quantidade | Percentual |
|---|---|---|
| 4000×3000 (12 MP) | 19867 | 61,7% |
| 4032×3024 (12 MP, iPhone) | 3529 | 11,0% |
| 3456×4608 (16 MP vertical) | 2631 | 8,2% |
| Outras (3120×4208, 4608×3456, 2448×3264…) | 6161 | 19,1% |
Em média, cada arquivo tem 11,5 megapixels e 2,96 MB; o maior arquivo individual tem 18,3 MB e 30 megapixels. Essas são exatamente aquelas fotos tiradas por um celular ou câmera e que você nunca se preocupou em gerenciar.
A pergunta é: quanto ainda se consegue extrair de uma imagem original intocada com uma ferramenta especializada de compressão?
2. Resultado: economia de 76,8% — 99,9 GB viram 23,1 GB
As 32188 imagens foram comprimidas uma a uma, sem alterar nome de arquivo, estrutura de diretórios ou resolução:
| Volume | Em relação ao original | |
|---|---|---|
| Originais direto da câmera | 99,9 GB | — |
| Depois do ImgZilla | 23,1 GB | -76,8% |
Uma única passada economizou cerca de 76,7 GB; depois da compressão, o volume caiu para menos de um quarto do original. Os 32188 arquivos mantiveram exatamente os mesmos caminhos relativos, nomes de arquivo e hierarquia de diretórios antes e depois — isso pode ser comprovado com os dados reais.
Comparação com o artigo anterior:
| Lote do teste | Origem das imagens | Taxa de compressão do ImgZilla |
|---|---|---|
| Artigo anterior (4624 arquivos) | Imagens finalizadas que já haviam sido comprimidas pelo site | -46,8% |
| Este artigo (32188 arquivos) | Imagens originais direto da câmera/celular | -76,8% |
A conclusão é direta: quanto mais crua a imagem original, maior o espaço que ainda pode ser explorado. A compressão feita na entrada do site já tinha consumido parte da redundância, deixando 46,8% para o ImgZilla; já as imagens direto da câmera não tiveram essa redundância tocada, então o ImgZilla consegue remover 76,8% de uma só vez.
3. Por que as imagens originais de câmera economizam tanto
Ao exportar JPEG, câmeras e celulares priorizam “não perder detalhes”, e não “deixar o arquivo o menor possível”. Por isso, os JPEGs diretos carregam um volume enorme que não contribui em nada para a qualidade visual:
- Parâmetros de qualidade conservadores: JPEGs diretos costumam usar tabelas de quantização com qualidade 90–98. O olho nu já não consegue notar a diferença trazida por uma qualidade maior, mas a quantidade de bytes muda bastante.
- Codificação entrópica genérica, não otimizada: a codificação direta usa tabelas Huffman padrão fixas, sem calcular a codificação ideal para cada imagem, sem quantização trellis, sem otimização de varredura progressiva.
- Diversos dados embutidos: EXIF, GPS, campos privados do fabricante, uma miniatura de visualização completa embutida, perfis de cores — tudo isso somado costuma representar dezenas ou centenas de KB.
O ImgZilla faz uma recodificação visualmente sem perdas para JPEG: utiliza estratégias de codificação melhores para reorganizar a codificação entrópica, reduz os parâmetros de quantização a uma faixa imperceptível a olho nu e remove dados embutidos redundantes. É verdade que há alteração no nível de pixel, mas os parâmetros ficam em um ponto em que a diferença praticamente não é visível. Por isso, em um material cheio de redundância como a “imagem original”, dá para remover três quartos de uma só vez.
É importante esclarecer um termo que costuma gerar confusão: “visualmente sem perdas” não é “sem perdas”. Sem perdas (pixels 100% inalterados) só existe em PNG (oxipng) e SVG; JPEG, WebP, AVIF, HEIC e GIF são, em princípio, recodificação com perdas — a diferença é que o parâmetro de compressão é escolhido na faixa visualmente sem perdas. Se você não quer acreditar apenas por esta frase, o ImgZilla tem uma janela de comparação integrada, com a imagem dividida em antes/depois, zoom até o tamanho real e comparação pixel a pixel — veja você mesmo.
4. Olhando mais de perto: taxa de compressão por arquivo, dimensões em pixels e casos extremos
Os 76,8% anteriores são a comparação de volume total do lote inteiro, com 32188 arquivos. Quando analisamos arquivo por arquivo, dá para observar algumas coisas mais específicas.
A grande maioria das imagens economiza 70%–90%
Pareamos as 32188 imagens uma a uma como “bytes antes → bytes depois” e as dividimos em faixas de economia:
| Faixa de economia | Quantidade | Percentual |
|---|---|---|
| 90%–100% | 866 | 2,7% |
| 80%–90% | 11375 | 35,3% |
| 70%–80% | 15244 | 47,4% |
| 60%–70% | 3349 | 10,4% |
| 50%–60% | 398 | 1,2% |
| Abaixo de 50% | 956 | 3,0% |
82,7% das fotos economizaram de 70% a 90%. A média aritmética da taxa de compressão por arquivo é 76,6%, quase igual aos 76,8% calculados pelo total de bytes — o que mostra que, neste lote, a distribuição entre arquivos que comprimem muito e os que comprimem pouco é relativamente uniforme em termos de peso de volume, sem ser puxada por um pequeno número de arquivos gigantes.
Por percentil: mais da metade das fotos economiza mais de 77%; mesmo os 10% com pior resultado economizam cerca de 68%; apenas cerca de 1% das fotos (p99) teve economia abaixo de 40%.
Dimensões dos pixels: nenhum pixel mudou
Ao verificar as mudanças de resolução nas 32188 imagens, dimensions_changed foi false em todas — 100% mantiveram a resolução original. O ImgZilla não redimensiona nem corta; os 76,7 GB economizados vêm completamente da recodificação, não de cortar pixels. Essa é a parte da definição de “compressão no local” que costuma passar despercebida: não apenas os nomes e caminhos dos arquivos continuam iguais; a resolução também permanece intacta.
Alguns casos extremos
| Tipo | Original | Após compressão | Economia |
|---|---|---|---|
| Maior taxa de compressão | 3,55 MB (4000×3000) | 100 KB | 97,2% |
| Maior economia em um único arquivo | 17,90 MB (4000×3000) | 1,13 MB | 16,8 MB |
| Menor ganho | 70 KB (1242×1242) | 68,8 KB | 2,1% |
As imagens com maior taxa de compressão (economia acima de 95%) normalmente são fotos tiradas com parâmetros de qualidade altíssimos e cheias de metadados; as de pior resultado são imagens que já eram muito pequenas, processadas antes. Em média, foram economizados 2,38 MB por imagem.
5. Convertendo em fatura mensal: quanto valem esses 76,8%?
Quando o volume é reduzido, é na conta que a diferença fica concreta. Abaixo não citamos nenhuma estatística tipo “compressão aumenta conversão”; fazemos apenas uma coisa: pegamos os 76,8% medidos e multiplicamos pelos preços públicos atuais de alguns provedores de nuvem, em uma conta puramente aritmética.
Economia no custo de armazenamento = volume economizado (GB) × preço unitário (yuan ou US$ / GB / mês)
Economia no custo de tráfego de saída = volume economizado (GB) × downloads no mês × preço unitário (yuan ou US$ / GB)
Custo de armazenamento
| Tamanho original do acervo | Volume economizado | Alibaba Cloud OSS Standard ¥0,09/GB/mês |
AWS S3 Standard US$0,023/GB/mês |
Google Cloud Storage US$0,020/GB/mês |
Cloudflare R2 US$0,015/GB/mês |
|---|---|---|---|---|---|
| 10 GB | 7,68 GB | ¥0,69/mês | US$0,18/mês | US$0,15/mês | US$0,12/mês |
| 100 GB | 76,8 GB | ¥6,91/mês | US$1,77/mês | US$1,54/mês | US$1,15/mês |
| 1 TB | 786 GB | ¥70,8/mês | US$18,1/mês | US$15,7/mês | US$11,8/mês |
| Este lote do teste (99,9 GB) | 76,7 GB | ¥6,90/mês | US$1,76/mês | US$1,53/mês | US$1,15/mês |
Essa é uma cobrança que se repete todos os meses: comprima uma vez e, a partir daí, cada fatura mensal será calculada sobre o novo volume — investimento único, benefício que se mantém ao longo do tempo.
Custo de tráfego: o verdadeiro vilão da conta
O custo de tráfego é o produto volume × número de downloads; quanto mais as imagens são acessadas, maior o benefício da compressão. Exemplo: um acervo de 100 GB gera 500 GB de tráfego de saída pelo CDN no mês (o equivalente a aproximadamente 5 downloads completos do acervo). Com a compressão, o tráfego cai na mesma proporção, -76,8%:
| Preço do tráfego de saída do CDN (primeira faixa) | Custo mensal antes da compressão | Depois | Economia mensal | Economia anual |
|---|---|---|---|---|
| Alibaba Cloud CDN (China continental) (¥0,15/GB) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront (Ásia-Pacífico) (US$0,12/GB) | US$60,0 | US$13,9 | US$46,1 | US$553 |
| Google Cloud CDN (América do Norte/Europa) (US$0,08/GB) | US$40,0 | US$9,3 | US$30,7 | US$369 |
Consideramos apenas o menor valor de cada faixa de preços dos provedores; na prática, os preços das faixas seguintes costumam ser mais altos. Quanto maior a fatura, mais significativa é a economia absoluta obtida com a compressão. Cloudflare R2 é a exceção: o tráfego de saída custa US$0, então o benefício aparece quase todo na conta de armazenamento.
Os preços acima são um apanhado das tarifas públicas de 2026 de cada plataforma. Os valores reais variam conforme região, desconto da conta e faixa de consumo; consulte sempre os preços atuais nos sites oficiais. O número de downloads é uma suposição hipotética; substitua pelos números reais da sua fatura.
6. Cenário local: quanto tempo de espera economizado ao mover esses dados
Como o volume cai 76,8%, o tempo de transferência diminui praticamente na mesma proporção — isso vale mesmo sem conta de nuvem e aparece diretamente no tempo de espera de cópias e backups.
- HD mecânico externo USB3: usando taxa de transferência contínua de 120 MB/s.
- SSD externo USB3: usando 450 MB/s.
- Rede com fio Gigabit: usando 105 MB/s, após descontar a sobrecarga de protocolo.
| Cenário | Volume economizado | HD mecânico USB3 | SSD USB3 | Rede Gigabit |
|---|---|---|---|---|
| Este lote do teste | 76,7 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Acervo de 10 GB | 7,68 GB | ≈66 s | ≈17 s | ≈75 s |
| Acervo de 100 GB | 76,8 GB | ≈11 min | ≈2,9 min | ≈12,5 min |
| Acervo de 1 TB | 786 GB | ≈112 min | ≈30 min | ≈128 min |
Como no custo de armazenamento, isso é investimento único, benefício contínuo: copiar para o HD externo e de volta, sincronizar com o NAS, rodar o Time Machine, migrar para um computador novo, enviar para um colega — enquanto esses dados estiverem sendo movidos, a economia de tempo acontece em todas as vezes nessa proporção.
7. E se a compressão acontecer antes do upload do usuário
Os cálculos anteriores são para a conta “depois que a imagem está armazenada”. Há ainda um trecho que vale ainda mais a pena calcular: o tempo entre o usuário clicar em “enviar” e a barra de progresso terminar usa a banda de upload do próprio usuário — e o upload é quase sempre o elo mais lento de toda a cadeia. As originais direto da câmera têm vários MB por arquivo e são uma ordem de grandeza maiores do que as imagens finalizadas do artigo anterior, que já tinham sido comprimidas pelo site e tinham em média 299 KB. Assim, a diferença de tempo fica muito mais perceptível.
Usando o volume médio por arquivo medido neste lote: as originais de câmera têm em média 2,96 MB; depois da compressão pelo ImgZilla, a média cai para 0,69 MB, economizando cerca de 2,27 MB por arquivo.
| Largura de banda de upload (faixas típicas de testes públicos de velocidade; apenas referência) | Arquivo único 2,96MB→0,69MB |
Upload de álbum com 50 fotos ≈148MB→34MB |
Upload de todo este lote (32188 arquivos) 99,9GB→23,1GB |
|---|---|---|---|
| Rede móvel (4G/5G combinados, assumindo 30 Mbps) | economia ≈0,6 s | economia ≈30 s | economia ≈5,7 h |
| Upload doméstico de banda larga comum (assumindo 25 Mbps) | economia ≈0,7 s | economia ≈36 s | economia ≈6,8 h |
| Upload simétrico de banda larga Gigabit (1000 Mbps) | economia ≈0,02 s | economia ≈0,9 s | economia ≈10 min |
Economizar 0,6 segundo por arquivo ainda não parece grande coisa. Mas, ao enviar um álbum inteiro de uma vez ou importar em lote algumas centenas de fotos originais da câmera, os minutos economizados são bem perceptíveis — especialmente para usuários de redes móveis, cujo upload já é naturalmente o mais lento.
Esses números de banda vêm de estatísticas públicas de testes de velocidade. As velocidades reais variam muito conforme operadora, região, equipamento e congestionamento da rede; use apenas como referência de ordem de grandeza.
8. Dados e notas sobre o teste
- Escopo da amostra: os dados deste artigo vêm dos testes reais com este lote de 32188 JPEGs direto de câmeras/celulares e refletem o resultado dessa amostra; não significam que “o ImgZilla comprime em média 76,8%”. Câmeras diferentes, modelos diferentes e resultados diferentes; imagens que já foram finamente otimizadas terão um espaço de exploração bem menor.
- Seleção da amostra: todo o lote foi comprimido sem nenhuma triagem ou limpeza, mantendo os 16 subdiretórios originais; não houve escolha de amostras favoráveis.
- Comparabilidade com o artigo anterior: no artigo anterior foram 46,8%; neste, 76,8%. A diferença vem quase toda de o material já ter sido comprimido ou não. A maioria das bibliotecas de imagens ficará entre esses dois números: as que já passaram por compressão na entrada se aproximam de 46,8%; as imagens cruas enviadas pela primeira vez pelos usuários se aproximam de 76,8%.
- Critério de cálculo: os 76,8% citados no texto representam “total de bytes economizados ÷ total de bytes originais”; a média aritmética da taxa de compressão por arquivo é 76,6%, e a mediana é 77,3%; ambos os critérios estão listados no corpo do artigo. As unidades são convertidas usando 1 GB = 10⁹ bytes.
- Parâmetros de compressão: os parâmetros são fixos e não há controle deslizante de qualidade na interface. Essa é uma decisão de design — para cada formato, os parâmetros são calibrados para o ponto de equilíbrio da faixa visualmente sem perdas. Usuários acostumados a ajustar manualmente devem ficar atentos a isso.
- Ambiente de execução: todo o processo foi feito localmente; as imagens nunca saíram deste Mac, e não foi necessário acesso à internet (exceto pela verificação de compra na App Store).
Fontes de preço de referência (tarifas públicas de 2026; para valores atualizados, consulte os sites oficiais de cada plataforma): AWS S3 Pricing, Tabela de preços do Alibaba Cloud OSS, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Tabela de preços do Alibaba Cloud CDN, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Quer verificar com seus próprios olhos? Baixe o ImgZilla direto da Mac App Store e faça um teste real com algumas imagens já processadas do seu site. Depois, decida se vale continuar comprimindo as demais.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Saiba mais: https://imagetool.app/ImgZilla
Requisitos do sistema: macOS 12.3 ou superior.