reCAPTCHA e moduli di contatto: il costo nascosto dell’anti spam e le alternative leggere

Quasi ogni sito ha un modulo di contatto, e quasi ogni modulo di contatto riceve spam. La soluzione più diffusa è aggiungere un CAPTCHA, spesso reCAPTCHA di Google, attivato con un clic nelle impostazioni del plugin dei moduli. È una scelta comprensibile, ma raramente se ne considera il costo: gli script anti spam più diffusi sono tra le risorse di terze parti più pesanti che un sito possa caricare, e con le impostazioni predefinite vengono spesso caricati su tutte le pagine, anche su quelle che non hanno alcun modulo.

In questo articolo vediamo quanto costano davvero, come limitarne l’impatto e quali alternative più leggere esistono, insieme agli altri elementi dei moduli che pesano sulle prestazioni: librerie per i campi, completamento degli indirizzi, moduli incorporati da servizi esterni.

Il costo di un CAPTCHA

Un CAPTCHA moderno non è un’immagine con lettere distorte: è un sistema che osserva il comportamento dell’utente e l’ambiente del browser per stimare se si tratta di una persona o di un programma. Per farlo carica uno o più script, spesso un iframe con un proprio documento, e raccoglie segnali durante la navigazione. Tutto questo significa connessioni a domini esterni, centinaia di kilobyte di JavaScript da scaricare, analizzare ed eseguire, e lavoro sul main thread, spesso sotto forma di task lunghi, proprio nella fase in cui la pagina si sta caricando.

Il costo si vede nei test di laboratorio, dove questi script compaiono regolarmente tra le prime voci del tempo di esecuzione delle terze parti, e nei dati reali, soprattutto sugli smartphone di fascia media. Può peggiorare l’INP, perché le interazioni avvenute mentre lo script viene eseguito devono attendere; e può ritardare l’LCP, perché lo script compete per la banda e per il main thread con le risorse della pagina.

La versione di reCAPTCHA che non mostra alcuna sfida all’utente, basata su un punteggio, è particolarmente insidiosa: la documentazione di Google suggerisce di caricarla su molte pagine del sito, non solo su quella del modulo, perché più dati raccoglie più il punteggio è affidabile. Diversi plugin seguono questa indicazione e la caricano ovunque. Il risultato è che un modulo usato da pochi visitatori impone un costo a tutti.

Caricarlo solo dove e quando serve

Il primo intervento, e spesso il più efficace, non richiede di cambiare strumento: basta limitare dove e quando lo script viene caricato.

Solo sulle pagine con il modulo. Molti plugin dei moduli caricano i propri script e fogli di stile su tutte le pagine, per semplicità. Contact Form 7, per esempio, offre filtri che permettono di disattivare il caricamento globale e di attivarlo solo dove il modulo è presente; altri plugin hanno un’opzione dedicata. In alternativa, i plugin di ottimizzazione permettono di escludere script specifici pagina per pagina. Il risultato è che le pagine senza modulo, di solito la grande maggioranza, non pagano nulla.

Solo quando l’utente inizia a compilare. Anche sulla pagina del modulo, non tutti i visitatori lo compileranno. Si può rimandare il caricamento dello script al primo contatto con i campi, per esempio quando uno dei campi riceve il focus. Il principio è lo stesso del ritardo del JavaScript al primo clic, applicato in modo mirato. Va gestito con attenzione: lo script deve essere pronto prima dell’invio, e i token generati da alcuni sistemi hanno una validità breve, di un paio di minuti, e vanno quindi richiesti al momento dell’invio e non al caricamento.

// Carica lo script anti spam al primo contatto con il modulo
const modulo = document.querySelector( '#modulo-contatti' );

modulo?.addEventListener( 'focusin', () => {
	const s = document.createElement( 'script' );
	s.src = 'https://servizio-anti-spam.example/api.js';
	s.async = true;
	document.head.appendChild( s );
}, { once: true } );

Le alternative più leggere

La seconda domanda è se un CAPTCHA serva davvero. Per la maggior parte dei moduli di contatto, lo spam arriva da programmi piuttosto semplici, che possono essere fermati con difese che non costano nulla all’utente.

• Il campo nascosto, detto anche honeypot: un campo invisibile alle persone ma presente nel codice, che i programmi automatici tendono a compilare. Se arriva compilato, il messaggio viene scartato. Non richiede script esterni e non disturba l’utente;
• il controllo del tempo: una persona impiega almeno qualche secondo a compilare un modulo, un programma lo invia in pochi millisecondi dal caricamento. Un controllo sul server che scarti gli invii troppo rapidi ferma una parte importante dello spam;
• il filtro del contenuto sul server: servizi come Akismet analizzano il messaggio dopo l’invio, sul server, e lo classificano come spam o no, senza aggiungere nulla alla pagina;
• le verifiche leggere senza sfida: strumenti come Cloudflare Turnstile, utilizzabile anche senza usare Cloudflare come CDN, o soluzioni basate su un piccolo calcolo svolto dal browser, come Friendly Captcha, offrono una verifica invisibile con un costo molto inferiore ai CAPTCHA tradizionali;
• le regole del firewall: limiti di frequenza e blocchi sui percorsi di invio dei moduli, come visto nell’articolo sul traffico automatico, fermano i bot prima ancora che raggiungano il sito.

La combinazione di campo nascosto, controllo del tempo e filtro lato server è sufficiente per moltissimi siti. Il CAPTCHA si può tenere come ultima risorsa, per i moduli più attaccati, come la registrazione o l’accesso, e caricato solo lì.

Privacy e consenso

C’è anche un aspetto normativo da non trascurare. I CAPTCHA basati sull’analisi del comportamento raccolgono dati sul dispositivo e sulla navigazione e li inviano a un fornitore esterno. Questo ha implicazioni per la privacy e, a seconda dell’interpretazione e della configurazione, può richiedere di informare l’utente o di raccoglierne il consenso, con effetti anche sul banner dei cookie. Le soluzioni lato server e quelle progettate per non raccogliere dati personali semplificano anche questo aspetto. È una valutazione da fare con chi segue la privacy del sito, ma è un argomento in più a favore delle difese leggere.

Gli altri pesi dei moduli

Il CAPTCHA non è l’unico costo nascosto di un modulo. Alcuni elementi frequenti:

• il completamento automatico degli indirizzi, che spesso carica la libreria completa di un servizio di mappe solo per suggerire le vie mentre l’utente scrive;
• le librerie per i campi: selettori di date, campi per i numeri di telefono con prefissi e bandiere, menu a tendina con ricerca. Alcune sono pesanti e dipendono da librerie più vecchie; i campi nativi del browser, come input type="date" o input type="tel", coprono molti casi senza script;
• la validazione a ogni tasto: controlli complessi eseguiti a ogni carattere digitato possono rendere lenta la risposta durante la scrittura. Gli attributi di validazione nativi, come required e pattern, e controlli eseguiti all’uscita dal campo sono più leggeri;
• i moduli incorporati da servizi esterni di marketing, sondaggi o prenotazione, che arrivano come script o iframe con tutto il loro peso: valgono i consigli dell’articolo sugli iframe di terze parti, a partire dal caricamento al momento dell’uso.

I moduli dei negozi online

Nei negozi online il discorso si estende ai moduli di accesso, registrazione e pagamento. I sistemi di pagamento caricano propri script per i campi della carta e per la prevenzione delle frodi, e alcuni di questi, come avviene per diverse integrazioni, raccomandano di caricarli su tutte le pagine del negozio, per raccogliere segnali utili a riconoscere i comportamenti sospetti. È una scelta che va valutata con il fornitore, perché riguarda la sicurezza dei pagamenti, ma spesso le integrazioni permettono di limitare il caricamento al carrello e al pagamento. Anche i moduli di accesso e registrazione, tra i più presi di mira dai bot, beneficiano più di limiti di frequenza e regole del firewall che di CAPTCHA caricati su tutte le pagine. Come visto nell’articolo su WooCommerce, il carrello e il pagamento sono pagine che non possono essere servite dalla cache, e ogni script in più pesa proprio nel momento in cui l’utente sta per concludere l’acquisto: tenerle leggere ha un effetto diretto sulle conversioni.

Moduli e CLS

I moduli possono causare anche spostamenti del layout. Il riquadro di un CAPTCHA con la casella da spuntare viene inserito da uno script in un secondo momento, e se non ha uno spazio riservato sposta i campi e il pulsante sottostanti. Lo stesso vale per i messaggi di errore che compaiono sopra i campi, o per i moduli caricati da servizi esterni che si ridimensionano dopo il caricamento. Riservare lo spazio con un’altezza minima, mostrare i messaggi in aree già previste e dare dimensioni fisse agli iframe dei moduli evita la maggior parte dei problemi, come visto nell’articolo sul CLS.

L’invio

L’interazione più importante di un modulo è l’invio, ed è anche quella in cui l’utente è più sensibile ai ritardi: se dopo il clic non succede nulla, tende a cliccare di nuovo o ad abbandonare. Conviene dare subito un riscontro visivo, disattivando il pulsante e mostrando un indicatore di attesa prima di eseguire la validazione e la richiesta al server, così che il browser possa aggiornare lo schermo nel fotogramma successivo al clic. Tutto il resto, come la generazione del token anti spam, l’invio dei dati e gli eventi di tracciamento della conversione, può avvenire dopo.

Come verificare

Per sapere se il sito paga il costo di uno script anti spam dove non serve, basta aprire una pagina senza moduli, come un articolo del blog, e cercare nel pannello Rete dei DevTools le richieste ai domini del servizio. Nel pannello Performance, la vista che raggruppa il tempo per prodotto mostra quanto tempo di main thread consuma lo script sulla pagina del modulo. Dopo l’intervento, la stessa verifica conferma che lo script compare solo dove previsto, e i dati reali delle pagine senza modulo, spesso le più visitate, dovrebbero migliorare.

Un esempio concreto

Uno studio professionale ha un sito con un centinaio di articoli e una pagina di contatto con un modulo protetto da reCAPTCHA nella versione basata sul punteggio. Il plugin dei moduli carica sia i propri file sia lo script di Google su ogni pagina, e il rapporto di Lighthouse sugli articoli mostra reCAPTCHA come la terza parte con il maggior tempo di esecuzione. Lo studio sostituisce reCAPTCHA con un campo nascosto, un controllo del tempo di compilazione e il filtro lato server, e limita il caricamento dei file del plugin alla sola pagina di contatto. Il numero di messaggi indesiderati resta sostanzialmente invariato, le pagine degli articoli non caricano più alcuno script anti spam e il tempo di blocco del main thread si riduce in modo visibile su tutte le pagine del sito.

In sintesi

Gli script anti spam più diffusi sono tra le terze parti più costose, e con le impostazioni predefinite vengono spesso caricati su tutto il sito. Il primo passo è caricarli solo sulle pagine con i moduli e, dove possibile, solo quando l’utente inizia a compilare. Il secondo è chiedersi se servano: campo nascosto, controllo del tempo e filtro lato server bastano per la maggior parte dei moduli di contatto, e le verifiche leggere senza sfida coprono molti degli altri casi. Completano il lavoro campi nativi al posto di librerie pesanti, spazio riservato per gli elementi che compaiono dopo il caricamento e un riscontro immediato al momento dell’invio.