Por que seus prints têm 2 MB, e como encolhê-los em 60–90%
Dov Azencot
@DovAzencotUma vez contei os prints numa única thread de e-mail de revisão de design. Onze deles, PNG, com média de pouco menos de 2 MB cada. Uns vinte e tantos megabytes de dashboards quase todos brancos, indo e voltando entre seis pessoas que tinham o mesmo app aberto em outra aba. Ninguém pensou nisso, porque "funcionava". É essa a armadilha. Prints são silenciosamente enormes, e o motivo está embutido na forma como seu computador os tira.
Por que um print é um arquivo de 2 MB
Quando você aperta o atalho de print, seu sistema operacional salva um PNG. É um padrão sensato — o PNG é sem perdas, então a captura fica perfeita pixel a pixel, e para um print cheio de texto nítido esse é genuinamente o instinto certo. O problema é o que o PNG faz com o tamanho.
O PNG guarda cada pixel exatamente. Uma tela moderna é densa — uma captura de janela inteira num display Retina ou 4K pode ter 2.000+ pixels de largura, e o PNG registra fielmente cada um desses milhões de pixels em fidelidade total. Não importa para ele que 60% do quadro seja o mesmo tom de quase branco. Ele não joga nada fora, porque jogar coisas fora não é o que ele faz. Então um print de uma página de configurações quase vazia — visualmente quase nada — ainda pesa de 1,5 a 2,5 MB, porque a tela é enorme mesmo quando o conteúdo é escasso.
A jogada: converter para WebP
O WebP consegue fazer algo que o PNG não consegue — comprimir com perdas mantendo bordas nítidas e transparência. Em prints especificamente, essa combinação é quase mágica, porque um print é feito na maior parte de regiões chapadas (baratas de comprimir) com um pouco de texto (que o WebP mantém nítido). A passagem com perdas descarta o ruído imperceptível; seu olho nunca registra queixa.
Números reais de prints no meu próprio disco:
| Como PNG | Como WebP | |
|---|---|---|
| Uma página de configurações, quase toda branca | 1,6 MB | ~180 KB |
| Um dashboard de análise completo | 2,4 MB | ~310 KB |
| Um editor de código em modo escuro | 1,9 MB | ~240 KB |
Isso é mais ou menos 85–90% a menos, e colocados lado a lado eu não consigo dizer qual é qual. O texto continua legível até o pixel. Essa é a conversão de maior retorno que eu faço, justamente porque os prints são tão absurdamente acima do peso para começar — há uma quantidade enorme de nada para espremer.
"O texto não vai ficar borrado?"
Esse é o medo, e é justo, porque você provavelmente já viu um print em JPG com texto borrado e com halo e presumiu que todo formato com perdas faz isso. O WebP é melhor em bordas que o JPG — significativamente melhor. Num ajuste de qualidade sensato, o texto num print WebP continua nítido. Já dei zoom de 400% caçando artefatos em volta das letras e voltei de mãos vazias em capturas normais de interface.
A exceção honesta: se você baixar a qualidade lá embaixo atrás de um arquivo minúsculo, você acabará vendo o texto amolecer. A solução é não fazer isso. Um ajuste de qualidade intermediário já te dá o ganho de 60–90% com o texto intacto. Não há motivo para empurrar até a faixa onde ele quebra.
Quando encolher não ajuda
Dois casos em que eu deixo o PNG em paz.
Se o print vai voltar para uma ferramenta de design para ser marcado, anotado ou composto, eu mantenho sem perdas. A passagem com perdas do WebP é uma porta de mão única, e eu não quero assar compressão dentro de algo que estou prestes a editar e reexportar. Publique o WebP, guarde o mestre PNG — a mesma regra de sempre.
E se um print já é pequeno — um detalhe recortado minúsculo, um único botão, algo já abaixo de uns 100 KB — a conversão mal move o ponteiro. O ganho de 60–90% vem de arquivos que são enormes porque a tela é enorme. Um recorte pequeno já resolveu esse problema. Não acrescente um passo à toa.
Como eu faço na prática
Eu passo os prints pelo conversor de PNG para WebP deste site antes de eles chegarem perto de um e-mail ou de um documento. Acontece no seu navegador, então a captura — que, convenhamos, muitas vezes mostra metade da sua tela e o que estava no fundo — nunca sai do seu dispositivo. Solte o PNG, veja a coluna de tamanho despencar, baixe o WebP, anexe esse no lugar.
O ponto maior não é a ferramenta, é o reflexo. Quando "tirou print, encolhe" vira automático, você para de disparar imagens de 2 MB para pessoas que já têm o app aberto, seus e-mails saem mais rápido, e as threads param de inchar até as dezenas de megabytes. Aquele e-mail de onze prints teria uns 2 MB no total em vez de vinte e tantos. As mesmas imagens. Tudo igual. Só sem o peso morto.
Artigos relacionados
Por que eu converto PNG para WebP (e a única vez em que não converto)
PNG é ótimo para editar e um desperdício para publicar. Aqui está o que o WebP realmente economiza, onde ele não muda nada e a única regra que eu nunca quebro.
AVIF vs WebP — o arquivo menor nem sempre é o certo
O AVIF costuma ganhar do WebP no tamanho, às vezes por 20% ou mais. Aqui está o que essa compressão extra custa em tempo de codificação e casos-limite, e quando eu ainda escolho WebP.
SVG para PNG — quando você realmente precisa de pixels (e quando não deveria)
Um SVG escala para sempre e continua minúsculo, então rasterizar parece um retrocesso. Às vezes é. Aqui está quando você de fato precisa de pixels PNG a partir de um vetor, e quando deixar o SVG em paz.
Todos os artigos