Contact Form 7 está ativo em mais de 5 milhões de sites. Funciona durante anos sem surpresas: instalar, configurar, esquecer. Mas assim que ativa a cache, os relatórios do PageSpeed Insights começam a mostrar uma linha persistente: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. O site não vai abaixo, visualmente está tudo impecável, apenas um indicador laranja de velocidade que estraga a imagem.

O culpado não é o plugin em si, mas o mecanismo de refill. Quando o CF7 deteta a constante WP_CACHE no wp-config.php, dispara atualizações AJAX para o CAPTCHA e elementos dinâmicos, o que faz sentido para páginas em cache. O problema é que o refill faz pedidos ao servidor de forma global. Mesmo em páginas onde não existe formulário nenhum.

A correção é uma edição cirúrgica de um único ficheiro, o controller.php. Três linhas, cinco minutos, e os pedidos de refill desaparecem dos relatórios. O método funciona em todas as versões atuais do Contact Form 7 (incluindo a 6.1.6, de maio de 2026) e no WordPress da 6.0 à 7.0.

💡 Resumo rápido:

• Abra o ficheiro controller.php na pasta do plugin
• Localize o bloco com a verificação do WP_CACHE, três linhas
• Comente-as ou elimine-as
• Guarde o ficheiro e limpe a cache a todos os níveis

O que o refill faz e porque prejudica a velocidade

Quando a constante define('WP_CACHE', true) está definida no wp-config.php, o Contact Form 7 trata todas as páginas como estando em cache. A lógica do programador é transparente: o HTML estático não atualiza o CAPTCHA sozinho, é preciso um endpoint AJAX que obtenha um novo código de verificação. O refill é exatamente esse endpoint.

Mas funciona sem olhar ao contexto. Os pedidos para /wp-json/contact-form-7/v1/contact-forms/<id>/refill são enviados a partir de todas as páginas em sequência: página inicial, blog, arquivo, qualquer uma. Num alojamento fraco ou num projeto com tráfego razoável, dezenas de chamadas REST desnecessárias por visualização de página atrasam significativamente o tempo de carregamento. O GTmetrix e o PageSpeed Insights destacam o refill como um recurso que bloqueia a renderização.

E o mais insidioso: visualmente o site funciona. Fica apenas com uma pontuação de velocidade «amarela» e não percebe logo onde deve investigar. A consola do navegador está silenciosa, sem erros, apenas números no relatório.

Vídeo: o que mais pode fazer com os scripts do Contact Form 7

Este pequeno vídeo em inglês mostra uma abordagem alternativa, o carregamento condicional dos scripts e estilos do CF7. As técnicas do vídeo combinam na perfeição com a nossa correção (vamos abordá-la mais abaixo).

Correção passo a passo: desativar o refill no controller.php

Passo 1. Chegar ao ficheiro

Caminho para o ficheiro dentro da pasta do plugin:

1
wp-content/plugins/contact-form-7/includes/controller.php

Duas formas de lá chegar. Através do painel de alojamento: gestor de ficheiros no cPanel (File Manager) ou equivalente, expanda a árvore de pastas pelo caminho acima. Via FTP: ligue-se com um cliente como o FileZilla e navegue até ao diretório do site.

Passo 2. Encontrar o bloco WP_CACHE

Abra o controller.php em qualquer editor de texto. Encontre as três linhas:

1
if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
    $wpcf7['cached'] = 1;
3
}

A mecânica é simples: se WP_CACHE estiver definida e ativa, o plugin define a flag cached = 1. Esta flag desencadeia uma cascata de pedidos de refill. De acordo com o código fonte do Contact Form 7, na versão 6.1.6 (maio de 2026) o bloco está no mesmo sítio e não mudou, ao longo de todo o histórico do ramo 6.x nunca foi alterado.

Passo 3. Comentar ou eliminar

É mais seguro comentar. Coloque // no início de cada linha:

1
// if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
//     $wpcf7['cached'] = 1;
3
// }

Porquê comentar em vez de eliminar: na próxima atualização do plugin, o controller.php será sobrescrito e a edição perder-se-á. Reconhecerá o bloco comentado imediatamente: abriu o ficheiro, viu //, lembrou-se. Eliminar funciona igualmente bem, mas ao fim de um mês ou dois é fácil esquecer o que cortou exatamente. Guarde o ficheiro.

Passo 4. Limpar a cache e verificar novamente

Após a edição, certifique-se de que limpa a cache a todos os níveis:

• Cache do plugin: WP Rocket → Painel → Limpar Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Cache do servidor: se o alojamento usar Varnish, Nginx FastCGI ou LiteSpeed LSCache ao nível do servidor, existe um botão para limpar no painel de alojamento.
• CDN: Cloudflare ou QUIC.cloud → Purge Everything.

Agora execute um novo teste no PageSpeed Insights ou no GTmetrix. Abra em modo anónimo, a cache do navegador pode mostrar a versão antiga do relatório.

O erro com /wp-json/contact-form-7/v1/contact-forms/<id>/refill deve desaparecer da secção «Eliminar recursos que bloqueiam a renderização» ou «Reduzir JavaScript não utilizado». Ainda aparece? Verifique o controller.php (a edição pode não ter sido guardada) e a cache de objetos (o Redis/Object Cache às vezes mantém a versão antiga do ficheiro em memória).

O que precisa de saber após a correção

A edição não é permanente. Cada atualização do Contact Form 7 sobrescreve o controller.php e as três linhas voltam. Após uma atualização, abra o ficheiro, confirme que o bloco está novamente ativo e comente-o de novo. Um minuto de trabalho, mas é fácil esquecer, mantenha uma lista de verificação.

O CAPTCHA pode deixar de funcionar. O refill foi originalmente concebido para o CAPTCHA em páginas com cache. Se usar o CAPTCHA integrado do Contact Form 7 (não o Google reCAPTCHA), após desativar o refill o código de verificação deixará de ser atualizado e o formulário não será enviado. Duas soluções: mude para o Google reCAPTCHA v3, que funciona através de uma API separada e não depende do refill; ou não comente o controller.php, mas configure o carregamento condicional dos recursos do CF7 através de filtros (mais sobre isto abaixo). Testou após a edição e o formulário é enviado normalmente? Ótimo, esqueça o assunto.

Abordagem alternativa, filtros wpcf7_load_js e wpcf7_load_css. Não desativam o refill, mas impedem o Contact Form 7 de carregar scripts e estilos em páginas sem formulário. Adicione ao functions.php do tema:

1
add_filter( 'wpcf7_load_js', '__return_false' );
2
add_filter( 'wpcf7_load_css', '__return_false' );

E na página com o formulário, dentro do hook wp_head, devolva as flags para true. Isto remove recursos desnecessários de todo o lado, exceto das páginas com formulários. Combine com a desativação do refill através do controller.php para obter o máximo desempenho.

⁉️🤔 Perguntas frequentes

É obrigatório editar o controller.php se não usar CAPTCHA?

Sim, é obrigatório. Os pedidos de refill para /wp-json/contact-form-7/v1/contact-forms/<id>/refill são enviados em cada ciclo AJAX, independentemente das definições de CAPTCHA. Visualmente não se notam, mas o GTmetrix e o Query Monitor registam chamadas desnecessárias à API REST. Depois de comentar as três linhas, o endpoint deixa de responder e a velocidade aumenta.

Porque não desativar simplesmente o WP_CACHE no wp-config.php?

A constante WP_CACHE é um sinal para todo o ecossistema WordPress de que as páginas podem ser colocadas em cache. O WP Rocket, W3 Total Cache, FlyingPress e outros plugins dependem dela. Ao remover o WP_CACHE, destrói completamente a cache, e a quebra de velocidade será muito mais notória do que um único pedido de refill. A forma correta: mantenha a cache, mas elimine o seu efeito secundário no CF7.

A correção funciona em multisite?

Funciona, mas o ficheiro wp-content/plugins/contact-form-7/includes/controller.php é partilhado por toda a rede. A edição afetará todos os sites filhos em simultâneo. Antes de fazer alterações, verifique se outros sites na rede têm formulários com o CAPTCHA integrado do Contact Form 7. Se sim, teste o envio em cada um deles após a edição, ou considere uma exceção por filtro em vez de uma edição global.

É possível automatizar a reposição da edição após uma atualização do plugin?

A documentação do Contact Form 7 não tem um filtro pronto para substituir exatamente estas três linhas. Na prática, uma lista de verificação «após atualização do CF7 → verificar controller.php» é mais fiável do que qualquer mu-plugin personalizado. O ficheiro muda raramente, ao longo de todo o ramo 6.x o bloco WP_CACHE nunca foi editado.

O formulário deixou de ser enviado após a edição, o que fazer?

Primeiro, verifique o tipo de CAPTCHA: Contact Form 7 → Integração. O CAPTCHA integrado do plugin (não o reCAPTCHA) depende do refill para alterar o código de verificação. Mude para o Google reCAPTCHA v3, que funciona através da sua própria API e não está ligado ao refill. Segunda opção: reverta a edição do controller.php, deixe o refill ativo e configure o carregamento condicional dos recursos do CF7 apenas nas páginas com formulários, através do wpcf7_load_js e wpcf7_load_css.

Contact Form 7 e cache: o que fazer em 2026

Editar o controller.php é uma microcirurgia que remove o único ponto de estrangulamento do plugin. Um minuto de tempo, sem plugins adicionais, funciona no WordPress da 6.0 à 7.0 e em todas as compilações atuais do Contact Form 7.

Quer extrair o máximo? Combine: desative o refill através do controller.php e configure o carregamento condicional de recursos através dos filtros wpcf7_load_js e wpcf7_load_css. O primeiro remove os pedidos de refill, o segundo impede que os scripts do formulário fiquem pendurados em páginas sem formulários. Juntos, retiram completamente o Contact Form 7 dos relatórios do PageSpeed Insights como fonte de problemas.

🔗 Contact Form 7 no WordPress.org