Configurar WebP e AVIF

Primeiro ver o que o teu servidor consegue

Na área «Imagens» está o cartão «Capacidades deste servidor». Ele não mostra o que está no papel, mas o que foi medido no PHP em execução: biblioteca de imagem GD com a respetiva versão, ler JPEG, ler PNG, ler WebP, escrever WebP, escrever AVIF. A pergunta é feita a dobrar — a função tem de existir e o formato tem de constar de imagetypes(). Isso é importante, porque alguns alojamentos compilam o GD sem WebP ou sem AVIF: nesse caso, imagewebp() existe e só falha quando é chamada.

Se faltar um formato, o interruptor correspondente continua visível, mas fica desligado e traz a justificação. Para o WebP, ela é: o GD tem de ser compilado com libwebp. Para o AVIF: PHP 8.1 ou mais recente com libavif. Ambos são assunto do teu alojamento. Um desvio pela chamada AJAX não ajuda — o servidor recusa expressamente ligar um formato que não está disponível.

A linha «Imagick» é pura informação. Este módulo não usa o Imagick; se aí estiver «não existe», não te falta nada.

Ligar e definir os três números

Há três interruptores e três campos numéricos. «Gerar WebP» e «Gerar AVIF» estão desligados de fábrica, «Entregar através de <picture>» está ligado. A separação é intencional: podes primeiro deixar que os ficheiros surjam e ligar a entrega mais tarde. Ao contrário vale o mesmo: se desligares a entrega, os ficheiros continuam a surgir, mas para os visitantes vai marcação inalterada.

A qualidade do WebP está em 82 e a do AVIF em 50. Ambos os campos aceitam valores de 30 a 100; tudo o que esteja acima ou abaixo é cortado para dentro desse intervalo. As predefinições diferentes não são um descuido: o AVIF mede de outra forma que o JPEG, e aí 50 já tem um aspeto muito limpo. Acima de 90, no WebP o ficheiro cresce mais depressa do que o ganho visível.

O limite máximo em megapíxeis está em 40 e aceita valores de 4 a 400. Protege contra o limite de memória: uma fotografia de 6000 × 4000 ocupa cerca de 96 MB ao ser descodificada, independentemente do tamanho do seu ficheiro. Além disso, antes de cada descodificação o Kakapo faz as contas com a memória realmente ainda livre e salta a imagem, em vez de deixar o carregamento morrer no limite.

Se alterares um dos três interruptores, o cache de páginas guardado é descartado. A qualidade e o limite de megapíxeis deixam-no ficar — só fazem efeito no carregamento seguinte e não tornam errada nenhuma página já guardada.

O que acontece ao carregar

A conversão decorre no fim do carregamento, assim que o WordPress tiver gerado todos os tamanhos de imagem. São processados o ficheiro dos metadados e cada tamanho gerado — não o original guardado pelo núcleo, que de qualquer forma nunca é entregue.

Cada ficheiro derivado fica como ficheiro acompanhante ao lado do seu original e leva o nome completo deste mais a extensão: de bild.jpg passa a bild.jpg.webp, e não bild.webp. Motivo: na mesma pasta podem estar lado a lado bild.jpg e bild.png; ao substituir apenas a extensão, um dos ficheiros derivados esmagaria o outro. Se no destino já houver alguma coisa, ela não é tocada.

Primeiro escreve-se num ficheiro auxiliar com o número do processo e um valor aleatório no nome. Só quando, depois de medido, for mais pequeno do que o original é que passa para o seu lugar por rename. Se for maior ou do mesmo tamanho, é eliminado e fica-se pelo original. Por isso, uma execução interrompida nunca deixa para trás um ficheiro derivado demasiado grande.

O carregamento tem um orçamento de tempo de 12 segundos. O AVIF é várias vezes mais lento a gerar do que o WebP, e seis tamanhos vezes dois formatos batem de outro modo no tempo de execução do servidor web — quem gere o site veria um carregamento interrompido. O que já não couber é recolhido por uma passagem posterior única: fica agendada 30 segundos mais tarde e dispõe então de 90 segundos. Tanto o que foi feito como o que foi saltado fica anotado no anexo, para que a mesma tentativa não se repita a cada nova geração.

Nos JPEG, uma rotação EXIF é aplicada a posteriori, porque o WebP e o AVIF vindos do GD não transportam essa indicação. Em originais PNG, o Kakapo tenta primeiro o WebP sem perdas — logótipos, gráficos e capturas de ecrã ficam assim muitas vezes mais pequenos, sem que as arestas se desfiem. A transparência mantém-se em ambos os formatos de destino.

Como é feita a entrega

O Kakapo envolve o <img> num <picture> e coloca à frente as fontes AVIF e WebP, primeiro o AVIF — o navegador escolhe a primeira fonte que entende. O <picture> recebe display:contents, para que nos layouts flex e grid do teu tema não empurre uma caixa adicional para dentro da disposição.

Escolha deliberada contra a alternativa via .htaccess: a negociação de conteúdo precisa de regras do Apache, não faz efeito nenhum no nginx e colide com os caches intermédios de CDN que não variam o cabeçalho Accept. Com <picture>, quem decide é o navegador, sem uma única linha de configuração do servidor.

A intervenção é feita sobre os conteúdos dos artigos e as imagens de destaque, com prioridade 22 — depois do Lazy-Load (20) e antes da reescrita de CDN (25), para que também as fontes recém-criadas passem pelo CDN. Os blocos <picture> já existentes ficam intocados, tal como as imagens de anfitriões externos e tudo o que esteja fora da pasta de uploads.

Vale a pena conhecer uma regra: um formato só é oferecido se a maior versão do srcset existir como ficheiro derivado. Se faltar uma média ou uma pequena, o navegador pega na imediatamente maior — alguns kilobytes a mais, mas nunca uma imagem desfocada. Se faltasse a maior, um ecrã largo já não conseguiria chegar à resolução completa; é exatamente esse caso que fica excluído.

Quando não surge nada: ler os motivos

O cartão «Ficheiros gerados & poupança real» mostra, por formato, o número de ficheiros, a soma dos originais, a soma dos ficheiros derivados e a diferença. Cada número resulta da comparação de dois tamanhos de ficheiro reais no momento da geração — nada é estimado nem extrapolado. «Originais» é aí apenas a soma dos ficheiros para os quais surgiu um ficheiro derivado, não todo o teu acervo multimédia.

Por baixo está o que não foi convertido, com o motivo. Os mais importantes:

«O resultado era maior do que o original» — não é um erro. Em miniaturas muito pequenas isso acontece regularmente com o AVIF; o original mantém-se e os restantes tamanhos recebem à mesma o seu ficheiro derivado.

«Não é gravável» — verifica as permissões na pasta de uploads. É o único motivo que realmente exige a tua intervenção.

«Já existia um ficheiro no destino» — não foi substituído. Na maioria das vezes vem da execução em lote sobre o acervo e é já exatamente aquilo que deveria surgir aqui.

«Não coube na memória» — aumenta o limite de megapíxeis ou o limite de memória do PHP.

«Não é legível» — ficheiro danificado, JPEG em CMYK ou uma variante exótica. «Não é JPEG/PNG/WebP» — as animações GIF e os PDF não são tocados de propósito.

Se o cartão estiver vazio, liga o WebP e carrega uma imagem. As imagens que já estão na biblioteca multimédia não são alcançadas por aí, mas sim através da execução em lote mais abaixo na mesma página.