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

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.

Erros relacionados

- [Como corrigir a integração de CDN do WP Rocket que não funciona](https://full.services/wp-fixer/corrigir-cdn-wp-rocket/)
- [Como corrigir o erro de fontes do Google no WP Rocket](https://full.services/wp-fixer/corrigir-fontes-google-wp-rocket/)
- [Como corrigir a exclusão de páginas do cache no WP Rocket](https://full.services/wp-fixer/corrigir-exclusao-cache-wp-rocket/)

## 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

1. 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
```

2. 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)
```

3. 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
```

4. 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
```

5. 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
```


## Código

```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.

**Fonte:** [WP Rocket — WebP Compatibility (Knowledge Base)](https://docs.wp-rocket.me/article/1282-webp)
