C’è un’ironia crudele nel mondo dell’A/B testing: lo strumento che hai installato per migliorare la conversione può essere quello che la sta affondando. Uno script di testing client-side integrato male aggiunge centinaia di millisecondi di JavaScript bloccante, provoca quello sfarfallio in cui l’utente vede la versione originale prima che compaia la variante, e degrada i Core Web Vitals che Google usa per il ranking — e che i tuoi utenti subiscono a ogni visita, che partecipino o meno a un test.
Nella nostra guida al CRO raccontiamo il processo: ricerca, ipotesi, prioritizzazione. Qui andiamo su ciò che quasi nessuno racconta: come eseguire i test tecnicamente senza pagare un pedaggio di prestazioni, senza spaventi con Google e senza conclusioni false.
Il costo nascosto dei tester client-side
La maggior parte degli strumenti popolari di A/B testing funziona allo stesso modo: inserisci uno snippet JavaScript, e quello script scarica la configurazione degli esperimenti, decide quale variante vede l’utente e modifica il DOM al volo. Comodo per il marketing, caro per tutti gli altri:
- Flicker (o FOOC, flash of original content): il browser dipinge la pagina originale e, millisecondi dopo, lo script la riscrive. L’utente vede il cambiamento avvenire. Oltre a dare la sensazione di un sito rotto, contamina l’esperimento — la variante che testi non è “il nuovo hero”, è “il vecchio hero che muta davanti ai tuoi occhi”.
- JavaScript bloccante: per evitare il flicker, molti strumenti raccomandano di caricare il loro script in modo sincrono nel
<head>, o peggio, con un “anti-flicker snippet” che nasconde l’intera pagina finché lo script non decide. Traduzione: il tuo LCP peggiora per il 100% delle visite, incluse quelle che non partecipano a nessun test. - Il paradosso della conversione: i Core Web Vitals incidono direttamente sulla conversione, soprattutto su mobile. Se il tuo tester aggiunge 300-500 ms di blocco, ogni test deve vincere parecchio solo per compensare ciò che il tester stesso ti toglie. Stai misurando miglioramenti del +5% con uno strumento che ti è costato un -3% di base.
Questo non significa che il client-side sia proibito — significa che ha un costo da misurare. Se installi un tester, confronta i tuoi Core Web Vitals prima e dopo. Molti team scoprono che il loro “programma di sperimentazione” era, al netto, un programma di degrado delle prestazioni.
Cosa dice Google su testing e SEO
La paura che “i test A/B penalizzano la SEO” è uno dei miti più persistenti. La posizione di Google è pubblica e abbastanza ragionevole: sperimentare è permesso, a quattro condizioni:
rel=canonicalsulle varianti. Se servi la variante su un’altra URL (/landing-b), quella URL deve puntare con il canonical all’originale. Così Google capisce che non è contenuto duplicato, ma una variazione temporanea della stessa pagina.- Redirect 302, non 301. Se reindirizzi traffico verso la variante, usa un redirect temporaneo (302). Un 301 dice a Google che il cambiamento è permanente e può trasferire l’indicizzazione alla URL del test.
- Niente cloaking. Googlebot deve poter vedere lo stesso di un utente qualsiasi: se rilevi il bot e gli servi sempre la versione originale “per sicurezza”, quello è cloaking e sì, è motivo di penalizzazione. Lascia che il bot entri nella ripartizione come un utente in più.
- Durata limitata. Un esperimento è temporaneo per definizione. Quando il test si conclude, implementa la variante vincente e smonta la macchina. Un test “vivo” per otto mesi smette di essere un esperimento e inizia a somigliare a contenuto duplicato con decorazione.
Rispettando questo, il rischio SEO reale di un test A/B non viene da Google che lo interpreta male: viene dal JavaScript bloccante che degrada i tuoi Core Web Vitals. Che è esattamente il punto precedente.
Server-side e feature flag: l’alternativa seria
Nel testing server-side, la decisione su quale variante servire si prende sul server (o all’edge) prima del rendering. L’utente riceve direttamente la versione che gli spetta: niente script di terze parti che riscrivono il DOM, niente flicker, nessun pedaggio di prestazioni.
Il modo moderno di implementarlo sono i feature flag: interruttori nel codice che attivano una variante per una percentuale di utenti, con assegnazione stabile (lo stesso utente vede sempre la stessa versione) ed esposizione registrata nella tua analytics. Strumenti open source come GrowthBook offrono l’infrastruttura completa — assegnazione, targeting, analisi statistica — e si integrano con il tuo data warehouse, così i dati non escono di casa. E per i casi semplici, dei flag fatti in casa (un’assegnazione per hash utente e un evento di esposizione) sono perfettamente dignitosi: meno di un giorno di lavoro e controllo totale.
| Client-side | Server-side / flag | |
|---|---|---|
| Velocità di caricamento | Penalizza LCP/INP (script bloccante) | Impatto nullo o marginale |
| Flicker | Frequente, difficile da eliminare del tutto | Inesistente |
| Capacità | Modifiche visive (copy, layout, CTA) | Qualsiasi cosa: flussi, logica, pricing, algoritmi |
| Chi lancia i test | Marketing, senza deploy | Richiede sviluppo e deploy |
| Costo di ingegneria | Basso all’inizio, debito dopo | Setup iniziale, economico dopo |
| Rischio SEO/CWV | Reale se integrato male | Minimo (rispettando canonical/302) |
La nostra regola pratica: client-side solo per test superficiali di copy o layout su pagine dove le prestazioni non sono critiche; server-side per tutto ciò che tocca il flusso di conversione, il prodotto o qualsiasi pagina che ti interessi nei motori di ricerca.
Statistica pratica, senza dogmi
Non serve un dottorato, ma sì tre discipline:
- Calcola campione e MDE prima di lanciare. Definisci l’effetto minimo rilevabile — il miglioramento più piccolo che giustificherebbe l’implementazione del cambiamento — e inserisci il tuo traffico in una qualsiasi calcolatrice di test. Se il risultato è “ti servono 14 settimane”, il test così com’è non è fattibile: cerca un cambiamento più grande, una metrica più frequente o una pagina con più traffico. Lanciare senza questo calcolo è il modo educato di lanciare una moneta.
- Il peccato del peeking. Guardare il risultato ogni giorno e fermarsi appena appare la significatività gonfia i falsi positivi fino a livelli assurdi: con abbastanza sguardi, quasi qualsiasi test “vince” prima o poi. La durata si fissa prima e si rispetta, coprendo cicli di business completi (i lunedì non convertono come i sabati).
- Sequenziali e bayesiani, se li capisci. Esistono metodi progettati per poter guardare senza barare: test sequenziali e approcci bayesiani (quelli che usa GrowthBook, per esempio) che danno una lettura continua onesta del rischio. Sono un’opzione legittima — non un trucco per fermarsi prima quando il risultato ti piace. Il metodo conta meno della disciplina: decidi le regole prima di vedere i dati.
QA degli esperimenti: il passaggio che tutti saltano
Un test è codice in produzione e merita lo stesso QA:
- Prova ogni variante su dispositivi reali. La variante B che stava perfetta sul desktop del designer può rompere il layout su un mobile di fascia media. Se metà del tuo traffico è mobile e la variante è rotta su mobile, il test non misura la tua ipotesi: misura un bug.
- Verifica l’analytics prima di lanciare. L’evento di esposizione si attiva una sola volta? La conversione si attribuisce alla variante corretta? Il tester non ha duplicato il pageview? Un esperimento con tracking rotto è peggio che non sperimentare: produce conclusioni con l’apparenza del rigore.
- Definisci guardrail metrics. Oltre alla metrica obiettivo, sorveglia quelle che non devono peggiorare: prestazioni (LCP, INP), tasso di errori JS e le metriche di business a valle — un CTA “vincente” nei clic che porta lead peggiori o meno ricavi per ordine è una sconfitta travestita. Se un guardrail si rompe, il test si ferma, qualunque cosa vinca la metrica principale.
Quando NON testare
Con poco traffico, un test A/B onesto impiega mesi o anni a dare un segnale, e la tentazione di “leggerlo comunque” produce decisioni casuali con travestimento scientifico. Come regola, sotto le ~1.000 conversioni mensili sulla pagina da testare, è meglio fare cambiamenti fondati — euristiche consolidate, ricerca qualitativa, cambiamenti grandi misurati prima/dopo con umiltà — che simulare la sperimentazione. Approfondiamo quando applicare ciascun approccio nella nostra guida al CRO.
Checklist prima di lanciare un test
- Ipotesi scritta, con metrica obiettivo e MDE definiti
- Campione e durata calcolati (e fattibili) prima del lancio
- Metodo scelto con criterio: server-side/flag per i test che contano
-
rel=canonicalsulle varianti con URL propria; redirect 302, non 301 - Googlebot vede lo stesso degli utenti (zero cloaking)
- Core Web Vitals misurati con la macchina di testing attiva
- Varianti provate su mobile e sui browser principali
- Eventi di esposizione e conversione verificati in analytics
- Guardrail metrics definite: prestazioni, errori, ricavi
- Data di fine fissata e impegno a non fare peeking
- Piano post-test: implementare la vincente e smontare l’esperimento
Conclusione
L’A/B testing ben eseguito è tanto un problema di ingegneria quanto di statistica: servire varianti senza degradare il sito, rispettare le regole di Google, misurare senza autoingannarsi e sorvegliare ciò che non deve rompersi. Per questo i test che contano si costruiscono dal codice — con feature flag, QA e guardrail — e non da uno snippet incollato nel <head>.
Vuoi sperimentare senza ipotecare le tue prestazioni né la tua SEO? Scopri il nostro servizio di growth marketing →