WebP WP Rocket Imagify: corrigir imagens que não carregam

Tipo Performance & Velocidade

Nome do erro Imagens WebP não carregam no WP Rocket com Imagify EN: WebP images not loading / not served

Severidade Atenção

Descrição As imagens WebP não carregam no WP Rocket com Imagify quando a opção WebP Compatibility do WP Rocket é ativada junto com o método de tag picture do Imagify, gerando cache duplicado e referências quebradas; o WP Rocket só deve cuidar do WebP quando o Imagify não serve a imagem sozinho.

O que é imagens WebP que não carregam no WP Rocket com Imagify?

O WebP que não carrega no WP Rocket com Imagify é um problema de servir a imagem, não de gerá-la. Quem converte o JPG ou PNG em WebP é o Imagify; quem entrega o arquivo certo ao navegador pode ser o próprio Imagify (pelo método de tag picture ou por regras de rewrite no .htaccess) ou o WP Rocket (pela opção WebP Compatibility, na aba Add-ons, que cria arquivos de cache separados com sufixo -webp). Quando as duas camadas tentam servir o WebP ao mesmo tempo, o navegador recebe uma referência que não bate com o arquivo em cache e a imagem some, fica quebrada ou volta para o formato antigo.

Segundo a documentação oficial do WP Rocket, a opção WebP Compatibility só deve ser usada quando o plugin de WebP não serve a imagem por conta própria. O Imagify é detectado automaticamente e, quando ele já entrega o WebP pelo método de tag picture ou por rewrite rules, o WP Rocket acinzenta a opção porque não há necessidade de um arquivo de cache separado. Forçar a ativação nesse cenário, ou empilhar o Imagify com Cloudflare e regras de rewrite, é o que faz a imagem WebP não carregar.

Como identificar

As imagens aparecem como espaços em branco, ícone de imagem quebrada ou caixa vazia somente em navegadores que suportam WebP (Chrome, Edge), enquanto carregam normal em navegadores sem suporte.
No DevTools do navegador, a aba Network mostra a requisição do arquivo .webp com status 404 Not Found ou retornando o JPG/PNG em vez do WebP esperado.
Imagens dentro do elemento picture, com a fonte do tipo image/webp, ficam vazias mesmo com o arquivo .webp existindo na pasta uploads.
Após ativar a opção WebP Compatibility do WP Rocket, imagens que antes apareciam pelo Imagify pararam de carregar ou passaram a piscar entre versões.
Com o Imagify em modo rewrite rules atrás do Cloudflare, alguns visitantes veem espaços em branco porque o WebP foi entregue a um navegador que não suporta o formato.

Antes de começar: Antes de alternar opções de cache do WP Rocket, trocar o método de exibição do Imagify ou editar o .htaccess, faça um backup completo do site (arquivos e banco) ou teste primeiro em um ambiente de staging, já que mudanças no .htaccess mal aplicadas podem derrubar o site inteiro com erro 500.

Como prevenir

Defina uma única camada responsável por servir WebP: deixe o Imagify entregar e mantenha o WebP Compatibility do WP Rocket desligado, ou o contrário, nunca os dois ativos.
Depois de trocar o método de exibição do Imagify entre tag picture e rewrite rules, limpe o cache do WP Rocket e do Cloudflare para descartar referências -webp antigas.
Em sites atrás de Cloudflare ou outro CDN, confira se o WebP é entregue com variação por navegador, para não enviar WebP a quem não suporta o formato.
Teste cada mudança em um navegador com suporte a WebP e em outro sem suporte, e revise as imagens de fundo CSS, que não são convertidas pelo método de tag picture.

Causa

A opção WebP Compatibility do WP Rocket (aba Add-ons) está ativada ao mesmo tempo que o Imagify serve WebP pelo método de tag picture: o WP Rocket cria arquivos de cache -webp que disputam com a marcação do Imagify, e a doc oficial afirma que nesse caso não é preciso criar arquivo de cache separado.
O Imagify está no método rewrite rules (.htaccess) atrás do Cloudflare: o Cloudflare pode cachear e servir a versão WebP a um navegador que não a suporta, resultando em espaços em branco, conforme alertado pela documentação do Imagify.
A imagem é um background definido por CSS: o método de tag picture do Imagify só substitui tags de imagem no HTML, então imagens de fundo via CSS nunca recebem a versão WebP e continuam servindo o formato antigo.
A imagem é carregada dinamicamente por JavaScript depois que a página foi processada: o Imagify não consegue aplicar a marcação de tag picture a imagens injetadas após o processamento, e o WebP não é entregue para esses elementos.
O cache do WP Rocket foi gerado com a referência -webp antiga e ficou desatualizado após trocar o método de exibição do Imagify, fazendo o navegador pedir um arquivo .webp que o servidor já não monta da mesma forma.

Como resolver

Decida quem serve o WebP: Imagify OU WP Rocket, nunca os dois: A regra da documentação do WP Rocket é direta: se o Imagify já entrega o WebP pelo método de tag picture ou por rewrite rules, a opção WebP Compatibility do WP Rocket deve ficar desativada, pois não há necessidade de um arquivo de cache separado. Deixe apenas uma camada responsável pela entrega.
```
Painel WP -> Imagify -> aba Otimização -> confira se 'Exibir imagens em formato Next-Gen no site' está ligado
Anote qual método o Imagify usa: tag picture ou rewrite rules
```
Desative o WebP Compatibility do WP Rocket quando o Imagify já serve: Vá até a aba Add-ons do WP Rocket e desligue a opção WebP Compatibility. Se ela já estiver acinzentada, é o próprio WP Rocket detectando o Imagify e avisando que não precisa atuar. Em seguida limpe o cache para descartar os arquivos -webp antigos.
```
Painel WP -> Configurações -> WP Rocket -> aba Add-ons (Complementos)
Desligue a opção 'WebP Compatibility'
Painel WP -> WP Rocket -> botão 'Limpar cache' (Clear cache)
```
Se o método de tag picture quebra o layout, troque para rewrite rules no Imagify: Quando a tag picture deixa imagens vazias por incompatibilidade de tema ou CSS, mude o Imagify para o método rewrite rules, que adiciona regras ao .htaccess e serve o WebP em segundo plano sem alterar o HTML. Exige servidor Apache ou Litespeed.
```
Painel WP -> Imagify -> Otimização -> 'Exibir imagens em formato Next-Gen no site'
Selecione o método 'Usar regras de rewrite' em vez de 'Usar tags picture'
Salve e recarregue a página em um navegador com suporte a WebP
```
Ajuste o Cloudflare para não servir WebP ao navegador errado: Se o Imagify estiver em rewrite rules atrás do Cloudflare e alguns visitantes virem espaços em branco, o Cloudflare está cacheando a resposta WebP e entregando a navegadores sem suporte. Force o cache a variar pelo cabeçalho de aceitação do conteúdo ou desligue o cache do WebP nessa camada.
```
Cloudflare -> Caching -> purgue todo o cache do site
Garanta que o servidor envie o cabeçalho 'Vary: Accept' nas imagens (ver código abaixo)
Reteste em Chrome e em um navegador antigo sem suporte a WebP
```
Trate imagens de fundo CSS e carregadas por JavaScript: Imagens definidas como background no CSS e imagens injetadas por JavaScript depois do carregamento não recebem a marcação de tag picture. Para esses casos, prefira o método rewrite rules do Imagify ou troque manualmente o caminho do arquivo para a versão .webp no CSS quando o suporte do público permitir.
```
Identifique no DevTools quais imagens não convertidas são background CSS ou injetadas por JS
Para essas imagens, use o método rewrite rules do Imagify (serve por .htaccess, independente da tag de imagem)
Em CSS estático, aponte a regra background para o arquivo .webp já gerado pelo Imagify
```

APACHE

# .htaccess — entregar WebP por content negotiation e evitar que CDN/Cloudflare
# sirva o WebP a navegadores sem suporte. Coloque ANTES das regras do WordPress.
<IfModule mod_headers.c>
  # Faz o cache (Cloudflare/proxy) variar a resposta pelo navegador que pede.
  <FilesMatch ".(jpe?g|png|gif|webp)$">
    Header append Vary Accept
  </FilesMatch>
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Só serve .webp quando o navegador o aceita E o arquivo .webp existe.
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
  RewriteRule ^(.+).(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1,L]
</IfModule>

Perguntas frequentes

Por que minhas imagens WebP não carregam só no Chrome com WP Rocket e Imagify

Porque o Chrome suporta WebP e pede a versão .webp, mas a referência servida não bate com o arquivo em cache. Isso acontece quando o WebP Compatibility do WP Rocket está ativo junto do método de tag picture do Imagify. Desative o WebP Compatibility e limpe o cache.

Preciso ativar o WebP Compatibility do WP Rocket se já uso o Imagify

Não. A documentação do WP Rocket diz que, quando o Imagify já serve o WebP pelo método de tag picture ou por rewrite rules, não é preciso criar arquivo de cache separado. O WP Rocket inclusive detecta o Imagify e acinzenta a opção nesse cenário.

Qual a diferença entre o método picture e o método rewrite rules do Imagify

O método de tag picture reescreve o HTML trocando as tags de imagem por blocos picture com fallback, mas pode quebrar layouts e não cobre imagens de fundo CSS. O método rewrite rules adiciona regras ao .htaccess e serve o WebP em segundo plano, exigindo servidor Apache ou Litespeed.

Por que algumas imagens aparecem em branco com o Imagify atrás do Cloudflare

Com o método rewrite rules, o Cloudflare pode cachear a resposta WebP e entregá-la a um navegador que não suporta o formato, gerando espaços em branco. Purgue o cache do Cloudflare e garanta que as imagens variem pelo cabeçalho Accept do navegador.

Por que minhas imagens de fundo definidas no CSS não viram WebP

O método de tag picture do Imagify só substitui tags de imagem no HTML, então imagens de fundo aplicadas por CSS nunca recebem a versão WebP. Para convertê-las, use o método rewrite rules, que serve pelo .htaccess, ou aponte manualmente o CSS para o arquivo .webp já gerado.

Limpar o cache do WP Rocket resolve o WebP que não carrega

Em parte. Limpar o cache descarta arquivos -webp desatualizados, mas se a causa for o conflito entre o WP Rocket e o Imagify servindo ao mesmo tempo, é preciso primeiro desativar o WebP Compatibility e só então limpar o cache para a correção valer.

O WP Rocket cria as imagens WebP sozinho

Não. O WP Rocket não converte imagens; ele só serve arquivos WebP que já existem, criando arquivos de cache com sufixo -webp. A conversão de JPG ou PNG em WebP é feita por um plugin como o Imagify, que gera os arquivos a partir das suas imagens.

Grave

Como corrigir o erro 404 após ativar o WP Rocket

O WP Rocket erro 404 surge quando o navegador pede um arquivo CSS/JS minificado, um asset de CDN ou uma página que o cache aponta para um caminho inexistente. Na maioria dos casos a causa é o nome do arquivo combinado mudar e a referência antiga ficar em cache.

Grave

Como corrigir TTFB alto no WordPress (Reduce server response time)

TTFB alto no WordPress é quando o Time to First Byte, o tempo entre o navegador pedir a página e receber o primeiro byte de resposta do servidor, passa de 600ms. Costuma vir de hospedagem lenta, ausência de cache de página, PHP não otimizado ou queries de banco demoradas que atrasam a geração da página.

Grave

Como corrigir o erro de JavaScript ao combinar arquivos no WP Rocket

A opção Combine JavaScript Files do WP Rocket junta todos os scripts em um único arquivo; quando dois scripts dependem de ordem ou de uma variavel global, a juncao gera erro de JavaScript e quebra menu, carrossel, slider ou formulário. A correção e excluir o arquivo conflitante do combine.

Grave

Como corrigir funcionalidades quebradas pelo Perfmatters

Funcionalidades quebradas pelo Perfmatters acontecem quando uma otimização do plugin remove ou atrasa um script ou estilo que a página precisava. As causas comuns são o Script Manager desativar um script necessário, o Delay JavaScript adiar o jQuery de um formulário ou slider, e o Remove Unused CSS cortar uma folha de estilo usada.

Atenção

Como corrigir o WP Rocket que não otimiza subdomínios no WordPress

O WP Rocket não otimiza subdomínios quando o plugin foi ativado em rede (Network Activate) em vez de ativado individualmente em cada subsite, ou quando o WordPress acessa o admin por uma URL diferente da do front-end, impedindo o plugin de gerar a configuração e o cache por domínio.

Grave

Como corrigir scripts do Tutor LMS removidos pelo Perfmatters no WordPress

O Perfmatters remove scripts do Tutor LMS quando o Script Manager desativa o JavaScript do plugin nas páginas de curso, ou quando o Delay JavaScript adia o carregamento dos scripts da sala de aula até uma interacao, deixando player de vídeo, quiz e progresso sem funcionar.

Setores

Extensões

Integrações

Como corrigir o erro de imagens WebP que não carregam no WP Rocket com Imagify

O que é imagens WebP que não carregam no WP Rocket com Imagify?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o erro 404 após ativar o WP Rocket

Como corrigir TTFB alto no WordPress (Reduce server response time)

Como corrigir o erro de JavaScript ao combinar arquivos no WP Rocket

Como corrigir funcionalidades quebradas pelo Perfmatters

Como corrigir o WP Rocket que não otimiza subdomínios no WordPress

Como corrigir scripts do Tutor LMS removidos pelo Perfmatters no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos