O WordPress guarda várias cópias de cada imagem e não otimiza nenhuma

Suba uma foto no WordPress e você não recebe um arquivo. Você recebe uma miniatura, uma média, uma média-grande, uma grande, o tamanho completo e todos os tamanhos extras que seu tema e seu construtor de páginas registraram. Seis ou oito arquivos a partir de um upload é o normal. Cada um é recodificado na qualidade JPEG padrão do WordPress e depois nunca mais é tocado.

Multiplique isso por alguns anos de publicações e a pasta de uploads costuma ser a coisa mais pesada do seu backup, e a parte mais lenta das suas páginas. A maior parte desse peso é evitável.

Onde o peso realmente está

São os JPEGs. As fotos dominam uma biblioteca típica, e o WordPress as codifica com uma qualidade fixa (82 por padrão) com um codificador antigo. É um padrão prudente e razoável, não um arquivo pequeno. Capturas de tela e logos armazenados como PNG somam mais, porque o PNG é o contêiner errado para muitos deles.

Há duas maneiras honestas de reduzir isso, e elas têm compromissos diferentes.

1. Recodificar no lugar

Pegue cada tamanho gerado e recodifique-o para uma versão menor do mesmo formato: o JPEG continua JPEG, o WebP continua WebP. Um codificador moderno tira cerca de um quinto a um quarto de um JPEG padrão do WordPress sem mudança visível.

O atrativo é que nada mais no seu site percebe. O nome do arquivo, as dimensões e a extensão são idênticos, então cada URL continua funcionando, em cada tema, em cada página em cache, em cada <img> escrito à mão. É a opção chata e segura, e para muitos sites é a correta.

O que ela não fará: mudar de formato. Um JPEG continua um JPEG, então você não obtém os ganhos maiores que um formato mais novo lhe daria.

2. Servir formatos de nova geração

Gere um AVIF (e um WebP) ao lado de cada original e sirva-o por meio de uma tag <picture>, mantendo o JPEG ou o PNG original como alternativa para navegadores mais antigos. É aqui que estão as economias de verdade: com qualidade equivalente, o AVIF precisa de muito menos bytes que o JPEG, e ele finalmente cobre também os seus PNGs. Nós medimos a diferença em cerca de 1.900 fotos se você quiser os números.

As ressalvas honestas, porque há algumas:

• Ela reescreve o HTML da página, o que a torna independente do tema, mas só mexe nas tags <img>. Um background-image em CSS não será trocado.
• Um lazy-loader em JavaScript que reescreve src em tempo de execução pode não pegá-lo. O loading="lazy" nativo funciona bem.
• O GIF ainda não é coberto.

Os originais ficam exatamente onde estão, então nada se perde, e os navegadores que não conseguem ler AVIF recorrem ao arquivo que já entendiam.

A parte com que as pessoas realmente se preocupam

Ambas as abordagens mantêm um backup de cada original, então qualquer imagem se restaura aos seus bytes exatos com um clique. Um arquivo só é substituído quando o novo é estritamente menor, então nada aumenta. E se uma otimização falha, ela é ignorada, não é fatal: seu upload nunca trava e uma imagem nunca fica escrita pela metade.

Fazendo isso

É isto que o Patu Optimizer faz. Novos uploads são otimizados automaticamente, uma única passagem em massa cuida de tudo o que já está na biblioteca, e você escolhe no lugar ou nova geração por site. Ele roda na API do Patu, então a codificação acontece fora do seu servidor. Uma chave gratuita basta para começar.

Comece com no lugar se quiser zero surpresas. Parta para a nova geração quando quiser os bytes e suas páginas usarem tags <img> normais. De qualquer forma, o objetivo é o mesmo: parar de entregar uma biblioteca de mídia duas ou três vezes mais pesada do que precisa ser.