Otimização moderna de imagens para WordPress

O AVIF é aceite por 96,35% da utilização de browsers que o caniuse mede (dados de 12 de outubro de 2026). O capítulo de media do Web Almanac 2024 encontrou-o em 1,0% das imagens em mobile. Uma distância de mais de 95 pontos não se explica pelos browsers. Explica-se pelo caminho de upload, pelo markup que escolhe o candidato e pelo momento em que o browser descobre que a imagem existe.

As imagens continuam a ser o maior bloco de bytes na maioria dos sites WordPress. Em 2026 o problema raramente é “falta de um plugin mágico”. É servir o formato certo, na largura certa, com prioridade correta no herói e com uma cadeia de entrega (origem ou CDN) que não force o browser a descarregar um JPEG de 2400 px para um cartão de 360 px.

Este guia cobre o fluxo prático: diagnóstico do elemento LCP, AVIF no núcleo do WordPress, srcset/sizes, fetchpriority, lazy loading, o papel de um CDN, o estado real do JPEG XL e os requisitos de acessibilidade. Sem teoria de compressão AI genérica e sem listas de “parceiros de performance”.

#Problemas do JPEG em imagens WordPress

Durante anos o fluxo era: exportar JPEG a 80%, carregar no Media Library, deixar o tema chamar the_post_thumbnail( 'large' ). Isso ainda funciona, mas deixa três falhas abertas.

1. Um único ficheiro grande para todos os ecrãs.
2. Um formato menos eficiente do que AVIF ou WebP na mesma qualidade perceptual.
3. Prioridade de rede errada: o herói compete com CSS, fontes e scripts de terceiros.

O browser moderno escolhe bem entre candidatos em <picture> ou num srcset bem declarado. O WordPress já emite srcset quando usa wp_get_attachment_image() e os tamanhos estão registados. O trabalho editorial e técnico é alimentar essa API com ficheiros bons e metadados honestos.

#Como identificar o elemento LCP no WordPress

Antes de converter seja o que for, confirme com dados de campo, e não com uma suposição, qual é o elemento Largest Contentful Paint de cada template. O Web Almanac 2024 mediu que em 68% das páginas mobile esse elemento é uma imagem, com uma mediana de 135 KB para a maior imagem. Lido ao contrário: nos restantes 32% o LCP é texto, e aí uma conversão para AVIF não move a métrica um milissegundo.

Há dois casos em que o núcleo do WordPress não pode ajudar, mesmo que o LCP seja uma imagem:

1. O elemento LCP não é uma tag img renderizada pelo núcleo. Um fundo CSS, o poster de um video, ou um page builder que escreve markup fora de wp_filter_content_tags(). O núcleo não dá prioridade ao que não vê, por isso o herói chega depois da folha de estilos que o referencia.
2. O elemento LCP muda consoante o breakpoint. A foto de cabeçalho em desktop e o cartão em mobile são elementos diferentes. Uma suposição estática acerta num dos dois.

Para esses dois casos existe o Image Prioritizer, que depende do Optimization Detective. O Optimization Detective recolhe URL Metrics de visitantes reais por breakpoint, e por isso sabe qual elemento foi o LCP em vez de o deduzir da ordem do documento. Com esses dados o Image Prioritizer acrescenta um preload de alta prioridade para a imagem LCP, como elemento LINK no HTML e como cabeçalho HTTP Link, e o preload cobre também fundos CSS (inline ou de folha de estilos) e posters de vídeo. Coloca fetchpriority=high num img só quando esse elemento é o LCP em todos os breakpoints, coloca fetchpriority=low nas imagens dentro do viewport inicial que estão ocultas (os slides dois e três de um carrossel, o caso clássico) e adia o carregamento de fundos declarados em atributos style inline. Não tem ecrã de definições e só atua quando já existem métricas de visitantes recolhidas.

Os dois plugins vêm da equipa de performance do núcleo, a mesma que publica em make.wordpress.org/performance. Não são ferramentas de terceiros: são o laboratório do que depois entra no WordPress, por isso o que hoje instala como plugin mostra a direção oficial do projeto.

#Como ativar AVIF no WordPress

O WordPress 6.5 acrescentou suporte para AVIF em fevereiro de 2024, numa alteração anunciada por Adam Silverstein. Desde então pode carregar e servir .avif tal como um JPEG, sem plugin, desde que a compilação de Imagick ou LibGD do servidor o saiba codificar. Essa condição tem um ecrã próprio no painel: Ferramentas > Diagnóstico, separador de informação, secção de gestão de multimédia (em inglês, Site Health > Info > Media Handling).

É aqui que convém descer da teoria para o alojamento real. Em alojamento partilhado (PTisp, Amen e ofertas semelhantes) não escolhe a compilação de ImageMagick: herda-a. A versão de PHP no painel não diz nada sobre os delegados do Imagick, e uma migração entre planos do mesmo fornecedor pode alterá-los. Abra o Diagnóstico depois de cada mudança e de cada atualização maior do servidor, e trate o resultado como um dado do projeto, não como uma verificação pontual. Um tema que dá AVIF por adquirido num servidor sem suporte não produz nada e também não avisa.

A segunda coisa a reter é que o núcleo não converte nada por si. Um JPEG carregado continua a ser JPEG, e os seus tamanhos intermédios também. O hook que muda isso é o image_editor_output_format, disponível desde o WordPress 5.8, que associa um tipo mime de origem a um tipo mime de saída:

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Três consequências antes de publicar esse filtro:

• O ficheiro original fica intacto. Só os tamanhos intermédios gerados adotam o novo formato, e é isso que mantém a biblioteca de media editável.
• Aplica-se só a uploads futuros. Os media existentes precisam de uma regeneração.
• O valor por omissão já não é vazio. Desde o WordPress 6.7 o núcleo inclui nesse filtro as associações de HEIC e HEIF para JPEG, por isso devolva o array que recebeu em vez de construir um novo. Quem escreveu return array( 'image/jpeg' => 'image/avif' ); em 2023 está hoje, sem saber, a desligar a conversão das fotos que chegam de um iPhone.

O outro ajuste do núcleo que condiciona cada upload é o big_image_size_threshold, 2560 píxeis desde o WordPress 5.3. Qualquer imagem mais larga ou mais alta é reduzida, e a cópia reduzida passa a ser o maior tamanho disponível. Os uploads PNG ficam fora desse escalonamento. Se o espaço do herói é mesmo mais largo do que 2560 píxeis, já está a servir uma imagem ampliada, e nenhum trabalho de formato corrige essa falta de nitidez.

#Quanto tempo demora codificar AVIF

A documentação de transformações da Cloudflare diz que codificar AVIF pode ser uma ordem de grandeza mais lento do que codificar para outros formatos, e que, se uma imagem for grande demais para ser codificada depressa, a Cloudflare recorre a WebP ou JPEG. A mesma aritmética aplica-se na sua origem, e com mais razão num plano partilhado com limite de processos. Converter de uma vez uma biblioteca de 40 000 elementos é um trabalho em lote com fila e janela horária, não um clique num ecrã de definições.

#Como regenerar miniaturas com WP-CLI

O filtro só chega aos uploads novos, por isso uma biblioteca existente precisa de uma passagem explícita. O wp media regenerate percorre os anexos e volta a criar os tamanhos intermédios com a configuração atual, incluindo o formato de saída que acabou de definir. Duas flags evitam a maior parte dos dissabores: --only-missing, para não repetir o que uma execução interrompida já fez, e --image_size, para limitar a passagem a um tamanho quando só esse mudou.

wp media regenerate --only-missing --yes

Limite a execução, não só o comando. Em alojamento partilhado, uma regeneração sobre dezenas de milhares de anexos disputa o mesmo CPU que serve o tráfego real, e o AVIF é o formato que mais pede. Divida a biblioteca por intervalos de ID, execute fora das horas de ponta e guarde o registo: a lista de anexos que falham é o inventário de originais corrompidos que ninguém vê há anos.

Se o resultado não convencer, a saída é repetir a passagem com outro ajuste de qualidade, não restaurar uma cópia de segurança. O original nunca foi tocado.

#AVIF ou WebP no WordPress

Segundo a nota de desenvolvimento do WordPress 6.5, as imagens AVIF podem ser até 50% mais pequenas do que JPEG com a mesma qualidade de imagem, e a diferença é maior em fotografias com céu, pele e fundos suaves. Com 96,35% de suporte no caniuse, o formato já é suportado o suficiente para o tratar como formato principal em sites de conteúdo e lojas.

O WebP não está “morto”. Continua a ser o fallback mais útil quando:

• o hosting não gera AVIF (Imagick sem libavif, ou só GD);
• um CDN antigo só negocia WebP;
• precisa de animação leve sem vídeo.

O padrão estável em HTML é um <picture> com source type="image/avif", depois image/webp, e um <img> final em JPEG ou PNG. O núcleo escreve um único src e um srcset, não <picture>, por isso sozinho não consegue servir AVIF aos browsers que o aceitam e JPEG aos restantes a partir do mesmo markup. Obtém um formato por cada tamanho gerado. Há duas respostas viáveis, e na prática excluem-se uma à outra.

Negociação de conteúdo na edge ou no servidor. O CDN lê o cabeçalho Accept e serve AVIF, WebP ou JPEG a partir de um só URL. O HTML fica simples. O custo é que a cache passa a depender dos cabeçalhos do pedido, por isso as chaves de cache têm de o ter em conta, e uma configuração descuidada serve AVIF a um cliente que não o aceita.

Fallback no markup. O plugin Modern Image Formats, parte do programa Performance Lab, gera tamanhos intermédios em formatos modernos no upload e, desde a versão 2.0.0, pode emitir elementos <picture> com fallback. A escolha por omissão é AVIF quando o servidor o suporta e WebP caso contrário, que é o valor certo para um plugin que não conhece a sua infraestrutura. As definições ficam em Definições > Multimédia. Tal como o filtro do núcleo, aplica-se a uploads novos.

E mantenha o JPEG. Fora do browser continua a ser o formato seguro para clientes de email, imagens Open Graph, cartões sociais, leitores de RSS e qualquer feed que um parceiro consuma. O Modern Image Formats guarda o upload original, mas por omissão gera os tamanhos intermédios de JPEG e PNG só no formato moderno. Se um feed ou um cartão social precisa de tamanhos intermédios em JPEG, ative a opção Output fallback images em Definições > Multimédia: o plugin passa a gerar o formato original ao lado do moderno em cada tamanho, à custa de mais disco e mais tempo por upload.

#Como usar srcset e sizes no WordPress

Formato eficiente com dimensão errada ainda estraga o LCP. Se o herói no telemóvel tem 390 px de largura CSS e o src aponta para um ficheiro de 2000 px, o browser descarrega megabytes a mais mesmo em AVIF.

O WordPress regista tamanhos com add_image_size() e, no render, wp_get_attachment_image_srcset() monta a lista de candidatos. O atributo sizes diz ao browser qual a largura CSS esperada em cada breakpoint. Sem sizes realista (por exemplo (max-width: 768px) 100vw, 720px), o browser pode escolher um candidato demasiado grande. Que tamanhos o WordPress cria por omissão e como registar os seus está explicado no guia sobre o TimThumb e a gestão nativa de imagens.

Checklist curto:

• Registe apenas os tamanhos que o tema usa (evite dezenas de crops mortos).
• Recrie miniaturas após mudar tamanhos (wp media regenerate, ver acima).
• No herói, confirme no DevTools Network a largura do ficheiro escolhido, não só o Content-Type.
• Em blocos Gutenberg, prefira imagens alinhadas ao content width do tema; uploads a 5000 px “porque depois cortamos” aumentam armazenamento e tempo de geração.

Documentação útil: a referência de wp_get_attachment_image_srcset no Developer Handbook e o material de imagens em web.dev explicam a mesma ideia pelos dois lados (CMS e browser).

#Fetchpriority e sizes auto no WordPress 6.3 e 6.7

O Largest Contentful Paint em landings e posts com herói fotográfico é normalmente a imagem acima da dobra. Três controlos importam mais do que “mais compressão”: que o herói não use lazy loading, que tenha fetchpriority="high" e que o browser o descubra cedo.

O conselho de acrescentar loading="eager" e fetchpriority="high" à mão está desatualizado há três anos para imagens de conteúdo. O WordPress 6.3 acrescentou wp_get_loading_optimization_attributes(), que calcula ambos os atributos para as imagens que passam pelo caminho de renderização do núcleo:

• A primeira imagem que cumpre o limiar recebe fetchpriority="high". Cumprir significa uma área mínima de 50 000 píxeis, largura vezes altura, ajustável com o filtro wp_min_priority_img_pixels.
• O loading="lazy" é omitido nas imagens perto do início do documento. O filtro do limiar é wp_omit_loading_attr_threshold, cujo valor por omissão subiu de 1 para 3 na 6.3.
• A função nunca emite fetchpriority="high" e loading="lazy" juntos, porque são instruções contraditórias.

O WordPress 6.7 acrescentou depois sizes="auto" para imagens com lazy loading, através de wp_img_tag_add_auto_sizes(). É a correção do erro de srcset mais antigo do WordPress: o atributo sizes gerado assumia que a imagem ocupava todo o viewport, por isso uma miniatura de barra lateral de 300 píxeis podia puxar em mobile um candidato de 1024. Como uma imagem lazy só carrega depois de o layout estar resolvido, o browser já pode usar a largura real. O núcleo antepõe auto só quando a imagem já tem loading="lazy", e acrescenta uma pequena regra CSS (wp_enqueue_img_auto_sizes_contain_css_fix()) para evitar um efeito secundário no layout.

A leitura útil das duas versões: a prioridade e a largura já não são decisões do tema. Se o seu template continua a forçar esses atributos à mão, o mais provável é estar a lutar contra o núcleo em vez de colaborar com o browser. Verifique o markup real do seu tema: builders e shortcodes antigos que escrevem <img> fora do caminho de renderização do núcleo não recebem estes atributos.

link rel=“preload” as=“image” no head, com o URL da variante mais provável (e, se usar <picture>, o imagesrcset/imagesizes adequados), continua a ser a ferramenta certa quando a imagem LCP é um fundo CSS ou vem de um builder. Preload de todas as imagens da página é contraproducente: só a candidata a LCP.

#Quando compensa um CDN de imagens no WordPress

Um CDN de imagens (Cloudflare Images, Imgix, Thumbor self-hosted, ou o resize edge do seu fornecedor) resolve bem três casos:

1. Audiência em vários países e origem numa só região.
2. Muitas variantes (loja com grelhas, galerias, retina).
3. Conversão AVIF/WebP na edge a partir de um master JPEG/PNG, sem saturar o PHP no upload.

Para funcionar, a cache key tem de incluir formato aceite, largura e, se existir, qualidade. Caso contrário serve a variante errada a metade do tráfego. Também precisa de URLs estáveis: query strings aleatórias a cada deploy invalidam a cache sem necessidade.

Na Cloudflare, o resize na edge significa um URL com a forma https://<ZONA>/cdn-cgi/image/<OPÇÕES>/<IMAGEM-ORIGEM>, em que a origem é um caminho absoluto no servidor ou um URL absoluto, e as opções são separadas por vírgulas. A que importa aqui é format=auto, que serve o formato mais eficiente que o cliente aceita. Três pontos da documentação mudam o planeamento:

• Tem de ser ativado por zona no painel antes de qualquer URL de transformação funcionar nesse host. É o motivo mais frequente para um URL bem escrito devolver o original sem redimensionar.
• As imagens de origem estão restritas à mesma zona por omissão. As origens aceites seguem uma lista que a Cloudflare documenta à parte do formato de URL: um subdomínio de media separado ou um bucket S3 tem de ser acrescentado a essa lista, ou a zona aberta a qualquer origem.
• format=auto pode recusar AVIF. Por causa do custo de codificação já referido, a Cloudflare recorre a WebP ou JPEG quando a imagem é grande demais para ser codificada depressa. O seu herói pode ser AVIF nos testes e WebP em produção, consoante as dimensões da origem, e essa diferença não aparece em nenhum relatório de plugin.

Um CDN não corrige um tema que injeta o herói via CSS background-image sem dimensões, nem um slider que carrega dez slides full-bleed no primeiro paint. Também não substitui um srcset e um sizes corretos: o browser escolhe o candidato antes de fazer o pedido, por isso um markup errado pede uma largura errada e a edge gera obedientemente essa largura errada. Corrija o markup e os bytes na origem; use o CDN para distribuição e resize.

#Que qualidade de compressão usar no WordPress

O WP_Image_Editor::$default_quality vale 82, obsoleto desde o WordPress 5.8.1 a favor de get_default_quality(), que devolve 86 para WebP e os mesmos 82 para JPEG e tudo o resto. O JPEG passa depois pelo filtro jpeg_quality, que corre depois de wp_editor_set_quality e por isso tem a última palavra.

Os dois filtros recebem argumentos diferentes, e confundi-los é a forma habitual de uma regra pensada para um formato acabar aplicada a todos. O wp_editor_set_quality recebe a qualidade por omissão, o tipo mime e, desde o WordPress 6.8, as dimensões, por isso permite variar a qualidade por formato e por tamanho. O jpeg_quality recebe só a qualidade e uma string de contexto como image_resize. Um portefólio de fotografia e uma biblioteca de capturas de interface não querem o mesmo número. Note também que qualidade 100 põe o AVIF em modo sem perdas, segundo a nota de desenvolvimento da 6.5, por isso “qualidade máxima” em AVIF significa ficheiros grandes.

Convém ainda saber como cada formato falha quando o número é baixo demais. O JPEG falha de forma visível, com blocos e halos que se veem até numa miniatura. O AVIF a qualidade baixa suaviza a textura fina: grão, tecido, folhagem e cabelo perdem detalhe enquanto os contornos ficam limpos. Esse modo de falha é muito mais difícil de ver em tamanho pequeno, por isso a revisão tem de ser feita em resolução completa e no template real, não na grelha da biblioteca de media.

E um aviso sobre os números. A ideia de que um codificador deteta uma cara, comprime o céu de forma agressiva e entrega uma poupança concreta de 70% circula sem fonte que a sustente. Trate qualquer número desse tipo como não verificado até o medir na sua própria biblioteca. Um painel de plugin que reporta uma percentagem poupada está a reportar ficheiros em disco, não o que o browser descarregou depois de a edge negociar o formato. Só contam duas medidas: os bytes entregues do recurso LCP e o resultado visual no template em que a imagem é publicada.

A verificação prática cabe em vinte minutos. Fixe um conjunto pequeno de imagens representativas da biblioteca real (uma cara, um produto em fundo branco, uma captura com texto pequeno e uma paisagem larga), codifique-o com cada ajuste candidato e veja o resultado em tamanho completo. Isso evita publicar um valor global que estrague a fotografia de produto.

#Que browsers suportam JPEG XL em 2026

É aqui que a maioria dos guias de 2026 se engana, incluindo a versão anterior deste. O JPEG XL mal começou a chegar à entrega.

A única mudança real chegou a 6 de outubro de 2026. O anúncio da Google diz: “O Chrome passa a incluir suporte de descodificação do formato de imagem JPEG XL (.jxl) a partir do Chrome 155” (Chrome for Developers, tradução própria). Os utilizadores do Chrome em desktop recebem-no à medida que o browser se atualiza nas semanas seguintes. O Edge, que usa o mesmo motor, ainda não o seguiu.

O caniuse indica 16,95% de suporte global para JPEG XL a 12 de outubro de 2026, contra 15,02% quando esta secção foi escrita pela primeira vez, e quase todo esse número é suporte parcial. O estado real, browser a browser:

O Web Almanac nem sequer mediu a utilização de JPEG XL em 2024, e explicou porquê: os browsers baseados em Chromium não suportavam o formato. É um sinal mais honesto do que qualquer gráfico de adoção, porque o conjunto de dados que mede a web inteira não o considerou um formato de entrega. O Chrome 155 muda os dados da próxima edição, não a conclusão para um site publicado este mês. A última linha da tabela decide a questão em qualquer mercado onde o tráfego mobile vem sobretudo de Android.

O que isto significa na prática:

• Como formato de arquivo ou de master, o JPEG XL é genuinamente bom. A transcodificação sem perdas de e para JPEG é uma função real e uma razão real para guardar masters em JXL. É uma decisão de armazenamento, não de entrega, e não toca no seu srcset.
• Se decidir servi-lo, tem de ir como primeiro <source type="image/jxl"> dentro de um <picture>, com uma fonte AVIF e um JPEG de fallback atrás. A grande maioria dos visitantes vai usar um dos fallbacks, por isso o ramo JXL não o poupa a construir o resto.
• Não o use como argumento para adiar o AVIF. O AVIF é o formato com 96,35% de suporte hoje.

E se o seu alojamento não consegue codificar AVIF, a resposta não é esperar pelo JPEG XL: é WebP, através de image_editor_output_format ou da definição do Modern Image Formats. O suporte de WebP está muito mais disponível em compilações antigas de Imagick e LibGD, e a distância entre JPEG e WebP é bem maior do que entre WebP e AVIF.

#Como otimizar imagens no WordPress passo a passo

Fluxo que escala sem drama operacional:

1. Upload: foto master em sRGB, largura máxima alinhada ao maior breakpoint do tema (por exemplo 1920 ou 2560 px, não 8000 px de câmara; o núcleo reduz de qualquer forma tudo o que passe de 2560 px).
2. Geração: o núcleo cria os tamanhos intermédios no formato do upload; image_editor_output_format, o Modern Image Formats ou o CDN acrescentam AVIF ou WebP.
3. Render: wp_get_attachment_image() (ou bloco Imagem) com srcset/sizes corretos.
4. Herói: deixe o núcleo aplicar fetchpriority="high" e omitir o lazy; preload só quando o herói é um fundo ou fica fora do markup do núcleo.
5. Resto: lazy; sem preload.
6. Monitorização: PageSpeed/CrUX no URL real, filtrando “LCP element” e peso da imagem.

Em hosting partilhado sem Imagick AVIF, a conversão na edge do CDN costuma ser mais barata do que trocar de servidor só por um codec.

#Erros comuns na otimização de imagens WordPress

• PNG em fotografias. PNG é para UI e transparência. Fotos em PNG incham o disco e a transferência.
• Qualidade 100 em JPEG/AVIF. A diferença face a um nível moderado raramente se vê, mas nota-se no peso, e em AVIF 100 significa modo sem perdas.
• Crops 1:1 e 16:9 gerados “por segurança” e nunca usados. Cada upload multiplica I/O e backups.
• Lazy no logótipo e no herói. Atrasa LCP e CLS se as dimensões não estiverem no markup.
• Dois plugins de otimização ao mesmo tempo. Um reescreve URLs, o outro serve WebP; o resultado é 404 ou double-processing.
• Ignorar width e height. Sem dimensões intrínsecas o layout salta quando a imagem chega.

#Requisitos de acessibilidade de imagens no WordPress

Esta parte costuma ficar fora dos guias de performance, e em Portugal é exigível. O Decreto-Lei n.º 82/2022, que transpõe o Ato Europeu da Acessibilidade, inclui os serviços de comércio eletrónico, com aplicação desde 28 de junho de 2025. Os requisitos remetem para a norma EN 301 549 e, através dela, para os critérios WCAG 2.1 de nível AA. Se o projeto é uma loja, uma universidade ou uma câmara municipal, o trabalho de imagens tem dois critérios a cumprir além de pesar pouco.

O primeiro é a alternativa em texto (1.1.1). Um alt vazio é correto e desejável numa imagem decorativa, e é um defeito numa imagem que transmite informação. O WordPress guarda esse campo na biblioteca de media, por isso uma auditoria é uma consulta à postmeta por _wp_attachment_image_alt, não uma revisão template a template.

O segundo toca diretamente neste tema: imagens de texto (1.4.5). Um banner promocional com o título queimado nos píxeis falha o critério, não se traduz nem se seleciona, e ainda é o pior candidato possível para AVIF, porque a suavização de textura fina que este formato aplica castiga sobretudo a tipografia pequena. Texto em HTML sobre a imagem resolve o problema legal e o de compressão ao mesmo tempo. O mesmo vale para capturas de interface com letra minúscula: se são ilustrativas, recorte-as e amplie-as antes de codificar, em vez de carregar o ecrã inteiro e confiar no codificador.

Uma nota relacionada, caso surja na mesma revisão: o SVG continua a ser a resposta certa para ícones, porque é independente da resolução e um só ficheiro cobre qualquer densidade de ecrã sem srcset. O núcleo não permite o upload por omissão porque um SVG pode transportar script. Se o ativar, sanitize no upload em vez de confiar em quem carrega o ficheiro.

#Checklist de otimização de imagens antes de publicar

• Quanto pesa o herói na variante móvel típica, comparado com a mediana de 135 KB da maior imagem no Web Almanac 2024?
• O Network mostra AVIF ou WebP no documento, não só na página de teste do plugin?
• sizes corresponde à largura CSS real do content/herói?
• Só uma imagem tem fetchpriority="high"?
• O CDN (se existir) responde 200 com cache-hit após o segundo pedido?
• CLS do herói está estável (dimensões ou aspect-ratio no CSS)?
• As imagens informativas têm texto alternativo, e o texto dos banners é HTML e não píxeis?

Se algum ponto falhar, corrija esse ponto antes de comprar mais tooling.

#Quando contratar ajuda para imagens WordPress

Se o tema vem de um builder legado, se a loja WooCommerce serve thumbnails inconsistentes por variação de produto, ou se o LCP oscila entre imagem e bloco de texto conforme o dispositivo, o problema deixa de ser “mais compressão” e passa a ser markup e arquitetura. O primeiro artefacto útil é então um inventário curto: os templates afetados, a origem de cada imagem e o elemento LCP atual e o seu tempo em cada template. Percorremos essa lista na otimização de velocidade WordPress, ou trabalhe com um desenvolvedor WordPress que ajuste tema, Media Library e CDN no mesmo fluxo, em vez de empilhar mais um plugin de imagens.

#Conclusão

Os formatos estão decididos. O AVIF tem 96,35% de suporte de browser e suporte nativo no WordPress desde a 6.5. O JPEG XL não tem nenhuma das duas coisas: o Chrome 155 começou a descodificá-lo a 6 de outubro de 2026, mas o Edge, o Chrome para Android e o núcleo do WordPress não, por isso fica fora do srcset por agora. O WebP é o fallback que funciona em todo o lado.

Otimizar imagens em WordPress em 2026 é uma sequência curta: confirmar o elemento LCP com dados de campo, ver o que o servidor consegue codificar, ativar a conversão dos tamanhos intermédios e regenerar por lotes, srcset e sizes honestos, deixar o núcleo gerir a prioridade, lazy só abaixo da dobra, CDN quando a distribuição o justifica, e por fim texto alternativo e imagens de texto. O utilizador não deve notar o codec; deve notar que a página abre depressa e que as fotos continuam nítidas no ecrã que está a usar.