Contact Form 7 équipe plus de 5 millions de sites. Il fonctionne des années sans surprise: installez, configurez, oubliez. Mais activez la mise en cache, et les rapports PageSpeed Insights commencent à afficher une ligne persistante: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Le site ne plante pas, visuellement tout est propre, juste un indicateur de performance orange qui gâche le tableau.

Le coupable n'est pas l'extension elle-même, mais le mécanisme de rechargement. Lorsque CF7 détecte WP_CACHE dans wp-config.php, il déclenche des mises à jour AJAX pour le CAPTCHA et les éléments dynamiques, ce qui est logique pour des pages en cache. Le problème, c'est que ce rechargement interroge le serveur de manière globale. Même sur des pages où il n'y a aucun formulaire.

La correction consiste en une modification chirurgicale d'un seul fichier, controller.php. Trois lignes, cinq minutes, et les requêtes de rechargement disparaissent des rapports. La méthode fonctionne sur toutes les versions actuelles de Contact Form 7 (y compris la 6.1.6, mai 2026) et WordPress de 6.0 à 7.0.

💡 Aperçu rapide:

• Ouvrez le fichier controller.php dans le dossier de l'extension
• Trouvez le bloc avec la vérification WP_CACHE, trois lignes
• Commentez-les ou supprimez-les
• Enregistrez le fichier et videz le cache à tous les niveaux

Ce que fait le rechargement et pourquoi il nuit à la vitesse

Lorsque la constante define('WP_CACHE', true) est définie dans wp-config.php, Contact Form 7 traite chaque page comme étant en cache. La logique du développeur est transparente: le HTML statique ne met pas à jour le CAPTCHA tout seul, il faut un point de terminaison AJAX qui récupère un nouveau code de vérification. Le rechargement est précisément ce point de terminaison.

Mais il fonctionne sans tenir compte du contexte. Les requêtes vers /wp-json/contact-form-7/v1/contact-forms/<id>/refill partent de toutes les pages à la suite: page d'accueil, blog, archives, n'importe laquelle. Sur un hébergement modeste ou un projet avec un trafic correct, des dizaines d'appels REST inutiles par page vue ralentissent sensiblement le temps de chargement. GTmetrix et PageSpeed Insights signalent le rechargement comme une ressource bloquant le rendu.

Et le plus insidieux: visuellement, le site fonctionne. Vous obtenez juste un score de vitesse «jaune» et ne comprenez pas immédiatement où chercher. La console du navigateur est muette, aucune erreur, juste des chiffres dans le rapport.

Vidéo: ce que vous pouvez faire d'autre avec les scripts de Contact Form 7

Cette courte vidéo en anglais montre une approche alternative, le chargement conditionnel des scripts et styles de CF7. Les techniques de la vidéo se combinent parfaitement avec notre correction (nous l'aborderons plus bas).

Correction pas à pas: désactiver le rechargement dans controller.php

Étape 1. Accéder au fichier

Chemin du fichier dans le dossier de l'extension:

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

Deux façons d'y accéder. Via le panneau d'hébergement: gestionnaire de fichiers dans cPanel (File Manager) ou équivalent, dépliez l'arborescence des dossiers selon le chemin ci-dessus. Via FTP: connectez-vous avec un client comme FileZilla et naviguez jusqu'au répertoire du site.

Étape 2. Trouver le bloc WP_CACHE

Ouvrez controller.php dans n'importe quel éditeur de texte. Trouvez trois lignes:

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

Le mécanisme est simple: si WP_CACHE est défini et actif, l'extension positionne le drapeau cached = 1. Ce drapeau déclenche une cascade de requêtes de rechargement. D'après le code source de Contact Form 7, dans la version 6.1.6 (mai 2026) le bloc se trouve au même endroit et n'a pas changé, sur toute l'historique de la branche 6.x il n'a pas été touché une seule fois.

Étape 3. Commenter ou supprimer

Il est plus prudent de commenter. Placez // au début de chaque ligne:

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

Pourquoi commenter plutôt que supprimer: lors de la prochaine mise à jour de l'extension, controller.php sera écrasé et la modification sera perdue. Vous reconnaîtrez immédiatement le bloc commenté: vous ouvrez le fichier, vous voyez //, vous vous souvenez. La suppression fonctionne tout aussi bien, mais dans un mois ou deux il est facile d'oublier ce que vous avez exactement coupé. Enregistrez le fichier.

Étape 4. Vider le cache et revérifier

Après la modification, assurez-vous de vider le cache à tous les niveaux:

• Cache d'extension: WP Rocket → Tableau de bord → Vider le cache; W3 Total Cache → Performance → Purger tous les caches; LiteSpeed Cache → LiteSpeed Cache → Purger tout; FlyingPress → FlyingPress → Vider le cache.
• Cache serveur: si l'hébergeur utilise Varnish, Nginx FastCGI ou LiteSpeed LSCache au niveau serveur, il y a un bouton de purge dans le panneau d'hébergement.
• CDN: Cloudflare ou QUIC.cloud → Purger tout.

Lancez maintenant un nouveau test dans PageSpeed Insights ou GTmetrix. Ouvrez en mode navigation privée, le cache du navigateur pourrait afficher l'ancienne version du rapport.

L'erreur avec /wp-json/contact-form-7/v1/contact-forms/<id>/refill devrait disparaître de la section «Éliminer les ressources bloquant le rendu» ou «Réduire le JavaScript inutilisé». Toujours présente? Vérifiez controller.php (la modification n'a peut-être pas été enregistrée) et le cache d'objet (Redis/Object Cache conserve parfois l'ancienne version du fichier en mémoire).

Ce que vous devez savoir après la correction

La modification n'est pas permanente. Chaque mise à jour de Contact Form 7 écrase controller.php, et les trois lignes reviennent. Après une mise à jour, ouvrez le fichier, assurez-vous que le bloc est de nouveau actif et commentez-le à nouveau. Une minute de travail, mais facile à oublier, tenez une liste de contrôle.

Le CAPTCHA peut se casser. Le rechargement a été conçu à l'origine pour le CAPTCHA sur les pages en cache. Si vous utilisez le CAPTCHA intégré de Contact Form 7 (pas Google reCAPTCHA), après avoir désactivé le rechargement, le code de vérification cessera de se mettre à jour et le formulaire ne pourra plus être envoyé. Deux solutions: passez à Google reCAPTCHA v3, il fonctionne via une API distincte et ne dépend pas du rechargement; ou ne commentez pas controller.php, mais configurez le chargement conditionnel des assets de CF7 via des filtres (plus de détails ci-dessous). Vous avez testé après la modification, le formulaire s'envoie normalement? Parfait, n'y pensez plus.

Approche alternative, les filtres wpcf7_load_js et wpcf7_load_css. Ils ne désactivent pas le rechargement, mais empêchent Contact Form 7 de charger les scripts et les styles sur les pages sans formulaire. Ajoutez au fichier functions.php du thème:

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

Et sur la page avec le formulaire, dans le hook wp_head, remettez les drapeaux à true. Cela supprime les assets inutiles partout sauf sur les pages contenant des formulaires. Combinez avec la désactivation du rechargement via controller.php pour obtenir des performances maximales.

⁉️🤔 Questions fréquentes

Est-il obligatoire de modifier controller.php si je n'utilise pas le CAPTCHA?

Oui, obligatoire. Les requêtes de rechargement vers /wp-json/contact-form-7/v1/contact-forms/<id>/refill sont envoyées à chaque cycle AJAX, indépendamment des paramètres du CAPTCHA. Visuellement, vous ne les remarquez pas, mais GTmetrix et Query Monitor enregistrent des appels API REST inutiles. Après avoir commenté les trois lignes, le point de terminaison cesse de répondre et la vitesse augmente.

Pourquoi ne pas simplement désactiver WP_CACHE dans wp-config.php?

La constante WP_CACHE est un signal pour tout l'écosystème WordPress indiquant que les pages peuvent être mises en cache. WP Rocket, W3 Total Cache, FlyingPress et d'autres extensions en dépendent. En supprimant WP_CACHE, vous détruirez entièrement la mise en cache, la baisse de vitesse sera bien plus perceptible qu'une seule requête de rechargement. La bonne approche: conservez la mise en cache, mais supprimez son effet secondaire dans CF7.

La correction fonctionnera-t-elle sur un multisite?

Elle fonctionnera, mais wp-content/plugins/contact-form-7/includes/controller.php est partagé sur tout le réseau. La modification affectera tous les sites enfants simultanément. Avant de faire les changements, vérifiez si d'autres sites du réseau ont des formulaires avec le CAPTCHA intégré de Contact Form 7. Si oui, testez l'envoi sur chacun après la modification, ou envisagez une exception par filtre au lieu d'une modification globale.

Peut-on automatiser le rétablissement de la modification après une mise à jour de l'extension?

La documentation de Contact Form 7 ne propose pas de filtre prêt à l'emploi pour remplacer précisément ces trois lignes. En pratique, une liste de contrôle «après mise à jour de CF7 → vérifier controller.php» est plus fiable que n'importe quel mu-plugin personnalisé. Le fichier change rarement, sur toute la branche 6.x le bloc WP_CACHE n'a pas été modifié une seule fois.

Le formulaire ne s'envoie plus après la modification, que faire?

Vérifiez d'abord le type de CAPTCHA: Contact Form 7 → Intégration. Le CAPTCHA intégré de l'extension (pas reCAPTCHA) dépend du rechargement pour changer le code de vérification. Passez à Google reCAPTCHA v3, il fonctionne via sa propre API et n'est pas lié au rechargement. Deuxième option: annulez la modification de controller.php, laissez le rechargement activé et configurez le chargement conditionnel des assets de CF7 uniquement sur les pages avec formulaires via wpcf7_load_js et wpcf7_load_css.

Contact Form 7 et mise en cache: que faire en 2026

Modifier controller.php est une microchirurgie qui supprime le seul goulot d'étranglement de l'extension. Une minute de temps, aucune extension supplémentaire, fonctionne sur WordPress de 6.0 à 7.0 et toutes les versions actuelles de Contact Form 7.

Vous voulez en tirer le maximum? Combinez: désactivez le rechargement via controller.php et configurez le chargement conditionnel des assets via les filtres wpcf7_load_js et wpcf7_load_css. Le premier supprime les requêtes de rechargement, le second empêche les scripts de formulaire de rester sur les pages sans formulaire. Ensemble, ils retirent complètement Contact Form 7 des rapports PageSpeed Insights en tant que source de problèmes.

🔗 Contact Form 7 sur WordPress.org