Contact Form 7 gira su oltre 5 milioni di siti. Funziona per anni senza sorprese: installi, configuri, dimentichi. Ma attiva la cache e i report di PageSpeed Insights iniziano a mostrare una riga persistente: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Il sito non va in crash, visivamente è tutto pulito, solo un indicatore di velocità arancione che rovina il quadro.

Il colpevole non è il plugin in sé, ma il meccanismo di refill. Quando CF7 rileva WP_CACHE in wp-config.php, attiva gli aggiornamenti AJAX per CAPTCHA ed elementi dinamici, cosa che ha senso per le pagine in cache. Il problema è che il refill colpisce il server a livello globale. Anche su pagine dove non c'è alcun modulo.

La soluzione è un intervento chirurgico su un file, controller.php. Tre righe, cinque minuti, e le richieste di refill spariscono dai report. Il metodo funziona su tutte le versioni attuali di Contact Form 7 (inclusa la 6.1.6, maggio 2026) e WordPress dalla 6.0 alla 7.0.

💡 Panoramica rapida:

• Apri il file controller.php nella cartella del plugin
• Trova il blocco con il controllo WP_CACHE, tre righe
• Commentale o cancellale
• Salva il file e svuota la cache a tutti i livelli

Cosa fa il refill e perché penalizza la velocità

Quando la costante define('WP_CACHE', true) è impostata in wp-config.php, Contact Form 7 tratta ogni pagina come se fosse in cache. La logica dello sviluppatore è trasparente: l'HTML statico non aggiorna il CAPTCHA da solo, serve un endpoint AJAX che recuperi un nuovo codice di verifica. Il refill è esattamente quell'endpoint.

Ma funziona senza alcun riguardo per il contesto. Le richieste a /wp-json/contact-form-7/v1/contact-forms/<id>/refill partono da tutte le pagine in serie: homepage, blog, archivio, qualsiasi cosa. Su hosting deboli o progetti con un traffico decente, decine di chiamate REST inutili per ogni visualizzazione rallentano sensibilmente il caricamento. GTmetrix e PageSpeed Insights segnalano il refill come una risorsa che blocca il rendering.

E la parte più subdola: visivamente il sito funziona. Ottieni solo un punteggio di velocità «giallo» e non capisci subito dove scavare. La console del browser è muta, nessun errore, solo numeri nel report.

Video: cos'altro puoi fare con gli script di Contact Form 7

Questo breve video in inglese mostra un approccio alternativo, il caricamento condizionale degli script e degli stili di CF7. Le tecniche del video si combinano perfettamente con la nostra correzione (ne parliamo più avanti).

Correzione passo passo: disabilitare il refill in controller.php

Passo 1. Raggiungi il file

Percorso del file all'interno della cartella del plugin:

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

Due modi per arrivarci. Tramite pannello di hosting: file manager in cPanel (File Manager) o equivalente, espandi l'albero delle cartelle seguendo il percorso sopra. Via FTP: connettiti con un client come FileZilla e naviga fino alla directory del sito.

Passo 2. Trova il blocco WP_CACHE

Apri controller.php in un qualsiasi editor di testo. Trova tre righe:

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

La meccanica è semplice: se WP_CACHE è definito e attivo, il plugin imposta il flag cached = 1. Questo flag innesca una cascata di richieste di refill. Secondo il codice sorgente di Contact Form 7, nella versione 6.1.6 (maggio 2026) il blocco è nello stesso posto e non è cambiato, in tutta la storia del ramo 6.x non è mai stato toccato.

Passo 3. Commenta o cancella

È più sicuro commentare. Metti // all'inizio di ogni riga:

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

Perché commentare invece di cancellare: al prossimo aggiornamento del plugin controller.php verrà sovrascritto e la modifica andrà persa. Riconoscerai subito il blocco commentato: apri il file, vedi //, ricordi. Cancellare funziona ugualmente, ma dopo un mese o due è facile dimenticare cosa hai tagliato esattamente. Salva il file.

Passo 4. Svuota la cache e ricontrolla

Dopo la modifica, assicurati di svuotare la cache a tutti i livelli:

• Cache del plugin: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Cache del server: se l'host utilizza Varnish, Nginx FastCGI o LiteSpeed LSCache a livello server, c'è un pulsante di svuotamento nel pannello di hosting.
• CDN: Cloudflare o QUIC.cloud → Purge Everything.

Ora esegui un test ripetuto su PageSpeed Insights o GTmetrix. Apri in modalità incognita, la cache del browser potrebbe mostrare la vecchia versione del report.

L'errore con /wp-json/contact-form-7/v1/contact-forms/<id>/refill dovrebbe sparire dalla sezione «Elimina le risorse che bloccano il rendering» o «Riduci JavaScript inutilizzato». Ancora presente? Controlla controller.php (la modifica potrebbe non essere stata salvata) e la cache oggetti (Redis/Object Cache a volte mantiene la vecchia versione del file in memoria).

Cosa devi sapere dopo la correzione

La modifica non è permanente. Ogni aggiornamento di Contact Form 7 sovrascrive controller.php e le tre righe tornano. Dopo un aggiornamento, apri il file, verifica che il blocco sia di nuovo attivo e commentalo nuovamente. Un minuto di lavoro, ma facile da dimenticare, tieni una checklist.

Il CAPTCHA potrebbe rompersi. Il refill è stato originariamente progettato per il CAPTCHA sulle pagine in cache. Se usi il CAPTCHA integrato di Contact Form 7 (non Google reCAPTCHA), dopo aver disabilitato il refill il codice di verifica smetterà di aggiornarsi e il modulo non verrà inviato. Due soluzioni: passa a Google reCAPTCHA v3, funziona tramite un'API separata e non dipende dal refill; oppure non commentare controller.php, ma imposta il caricamento condizionale degli asset di CF7 tramite filtri (ne parliamo più avanti). Dopo la modifica il modulo si invia normalmente? Ottimo, dimenticatene.

Approccio alternativo, filtri wpcf7_load_js e wpcf7_load_css. Non disabilitano il refill, ma impediscono a Contact Form 7 di caricare script e stili sulle pagine senza modulo. Aggiungi al functions.php del tema:

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

E sulla pagina con il modulo, dentro l'hook wp_head, riporta i flag a true. Questo rimuove gli asset non necessari da tutte le pagine tranne quelle con i moduli. Combina con la disabilitazione del refill tramite controller.php per ottenere il massimo delle performance.

⁉️🤔 Domande frequenti

È obbligatorio modificare controller.php se non uso il CAPTCHA?

Sì, obbligatorio. Le richieste di refill a /wp-json/contact-form-7/v1/contact-forms/<id>/refill vengono inviate a ogni ciclo AJAX indipendentemente dalle impostazioni del CAPTCHA. Visivamente non le noti, ma GTmetrix e Query Monitor registrano chiamate API REST non necessarie. Dopo aver commentato le tre righe, l'endpoint smette di rispondere e la velocità aumenta.

Perché non disabilitare semplicemente WP_CACHE in wp-config.php?

La costante WP_CACHE è un segnale per l'intero ecosistema WordPress che le pagine possono essere messe in cache. WP Rocket, W3 Total Cache, FlyingPress e altri plugin si basano su di essa. Rimuovendo WP_CACHE, distruggi completamente la cache, il calo di velocità sarà molto più evidente di una singola richiesta di refill. Il modo corretto: mantieni la cache, ma elimina il suo effetto collaterale in CF7.

La correzione funziona su multisite?

Funziona, ma wp-content/plugins/contact-form-7/includes/controller.php è condiviso su tutta la rete. La modifica influenzerà tutti i siti figli simultaneamente. Prima di apportare modifiche, verifica se altri siti nella rete hanno moduli con il CAPTCHA integrato di Contact Form 7. Se sì, testa l'invio su ciascuno di essi dopo la modifica, oppure considera un'eccezione tramite filtro invece di una modifica globale.

Si può automatizzare il ripristino della modifica dopo un aggiornamento del plugin?

La documentazione di Contact Form 7 non ha un filtro già pronto per sostituire esattamente queste tre righe. In pratica, una checklist «dopo aggiornamento CF7 → controlla controller.php» è più affidabile di qualsiasi mu-plugin personalizzato. Il file cambia raramente, in tutto il ramo 6.x il blocco WP_CACHE non è mai stato modificato.

Il modulo ha smesso di inviare dopo la modifica, cosa fare?

Per prima cosa controlla il tipo di CAPTCHA: Contact Form 7 → Integrazione. Il CAPTCHA integrato del plugin (non reCAPTCHA) dipende dal refill per cambiare il codice di verifica. Passa a Google reCAPTCHA v3, funziona tramite la propria API e non è legato al refill. Seconda opzione: annulla la modifica di controller.php, lascia il refill attivo e imposta il caricamento condizionale degli asset di CF7 solo sulle pagine con i moduli tramite wpcf7_load_js e wpcf7_load_css.

Contact Form 7 e caching: cosa fare nel 2026

Modificare controller.php è una microchirurgia che rimuove l'unico collo di bottiglia del plugin. Un minuto di tempo, nessun plugin aggiuntivo, funziona su WordPress dalla 6.0 alla 7.0 e su tutte le build attuali di Contact Form 7.

Vuoi ottenere il massimo? Combina: disabilita il refill tramite controller.php e imposta il caricamento condizionale degli asset tramite i filtri wpcf7_load_js e wpcf7_load_css. Il primo rimuove le richieste di refill, il secondo impedisce che gli script del modulo restino in attesa su pagine senza moduli. Insieme fanno sparire completamente Contact Form 7 dai report di PageSpeed Insights come fonte di problemi.

🔗 Contact Form 7 su WordPress.org