L'effetto sfarfallio nei test A/B: perché falsa i risultati (e come evitarlo)

Aggiornato il 19 ottobre 2026

13 millisecondi. Questo è il tempo di cui il cervello umano ha bisogno per identificare un'immagine, secondo uno studio condotto da neuroscienziati del MIT e pubblicato nel 2014. Tuttavia, lo script di uno strumento di test A/B lato client spesso impiega diverse centinaia di millisecondi per modificare la pagina. Durante questo lasso di tempo, il visitatore visualizza prima la versione originale e poi la variante. Le ha viste entrambe. Il test, tuttavia, presuppone che ne abbia vista solo una.

Questo effetto di sfarfallio introduce una distorsione sistematica nelle misurazioni, quasi sempre a scapito della variante, e può indurre a scartare una buona idea o a convalidarne una cattiva. Questa guida spiega da dove proviene, quanto costa effettivamente, come misurarlo sul proprio sito e come eliminarlo.

Che cos'è l'effetto sfarfallio nei test A/B?

L'effetto flicker (o FOOC, "Flash of Original Content") è la breve visualizzazione della pagina originale prima dell'applicazione della variante testata, poiché lo script di test modifica la pagina dopo che il browser ha iniziato a visualizzarla. Il visitatore percepisce un salto: un titolo che cambia, un pulsante che cambia colore, un blocco che si sposta.

Questo fenomeno è specifico dei test lato client. In questo modello, il server invia sempre la stessa pagina HTML; è un file JavaScript, caricato dal browser, che decide a quale gruppo appartiene il visitatore e riscrive il DOM di conseguenza. Finché questo script non viene scaricato, interpretato ed eseguito, il controllo viene visualizzato. Se non hai familiarità con questo vocabolario (DOM, variante, controllo, allocazione), il nostro glossario dei test A/B ripete ogni termine.

Perché Flicker falsa i tuoi risultati

Lo sfarfallio interessa solo uno dei due gruppi: il display di controllo non presenta artefatti, mentre la variante mostra un lampeggio. Pertanto, non si sta più confrontando "design A contro design B", bensì "design A contro design B con un difetto di visualizzazione". Si tratta di una distorsione, non di rumore: non si annulla aumentando la dimensione del campione.

Due meccanismi contrastano la variante:

1. Perdita di fiducia. Una pagina che "salta" suggerisce un sito web mal progettato. In un funnel di pagamento o in un modulo di richiesta di preventivo, questa sola impressione è sufficiente a destare sospetti.
2. L'effetto del confronto. Il visitatore ha già visto il vecchio prezzo, il titolo o l'immagine. Se la variante propone un prezzo barrato o una promessa più allettante, il visitatore visualizza entrambe le versioni, il che modifica la sua percezione dell'offerta.

A volte, al contrario, l'elemento che "appare" cattura l'attenzione e amplifica la variante. In entrambi i casi, il risultato che leggi nel tuo dashboard di analisi non corrisponde a come apparirebbe la variante una volta distribuita codificata in modo rigido, senza uno script. Questa è una delle fonti sottovalutate di falsi positivi (e falsi negativi) nei test A/B.

Le 5 cause tecniche dello sfarfallio

Lo sfarfallio compare non appena la variante viene applicata dopo il rendering della prima pagina. Cinque fattori, che possono combinarsi tra loro, allungano questo ritardo.

1. Posizione dello script

Uno script posizionato alla fine di <body> viene eseguito solo dopo che il resto dell'HTML è stato analizzato: il browser ha già visualizzato tutto. Deve essere il più in alto possibile nel <head>, prima dei fogli di stile e degli altri script di terze parti.

2. Utilizzo di un tag manager

Google Tag Manager carica i suoi tag in modo asincrono. Lo script di test, pertanto, attende il caricamento del contenitore GTM stesso prima di essere attivato. L'analista Simo Ahava ha misurato la discrepanza sullo stesso sito, con il traffico diviso in due: la pagina è rimasta nascosta. 964 ms in media con il tag che passa attraverso GTM, rispetto a 581 ms con lo snippet inserito direttamente nella pagina. Quasi 400 ms persi unicamente a causa del metodo di integrazione.

3. Caricamento asincrono

Uno script asincrono non blocca la visualizzazione: questo è il suo vantaggio in termini di velocità, ed è anche il motivo per cui produce sfarfallio. Torneremo su questo argomento nella prossima sezione.

4. Dimensioni dello script e latenza

Un file contenente la configurazione per tutti i test dell'account, inclusi quelli in pausa, richiede più tempo per essere eseguito. Se viene servito da un server distante dal visitatore, ogni scambio di dati aggiunge decine di millisecondi.

5. Il modo in cui la variante è codificata

Una modifica che attende che un elemento esista nel DOM prima di riscriverlo (ad esempio, "sostituisci il testo del pulsante una volta caricato") verrà necessariamente applicata dopo che è stata visualizzata. Gli editor WYSIWYG a volte generano questo tipo di codice per impostazione predefinita. La documentazione per Optimizely lo riconosce: le sue modifiche visive attendono che l'elemento sia disponibile, il che provoca dei lampeggi quando ci sono molte modifiche in coda.

Snippet sincrono o asincrono: la vera decisione

Un frammento di codice sincrono blocca la visualizzazione fino alla sua esecuzione: niente sfarfallio, ma una schermata bianca se lo script è lento. Un frammento di codice asincrono consente il caricamento della pagina: niente schermata bianca, ma sfarfallio. Non esiste una terza via gratuita.

Optimizely consiglia di caricare lo snippet in modo sincrono pur consentendo l'esecuzione asincrona di alcune modifiche alle varianti. VWO (rinominato) Wingify nel 2026) nasconde il corpo della pagina in attesa della sua libreria; Kameleoon evidenzia un'integrazione "asincrona bloccante".

La scelta giusta dipende da una sola domanda: la latenza del tuo script è sotto controllo? Se il file è piccolo e viene servito da una CDN vicina ai tuoi visitatori, la modalità sincrona aggiunge qualche decina di millisecondi ed elimina il problema. Altrimenti, ogni rallentamento della rete si traduce in una schermata vuota. Questo è il punto cruciale. diffusione ultraveloce delle varianti : rendere la modalità di blocco abbastanza breve da risultare impercettibile.

Il codice anti-sfarfallio: utile, ma ha un costo.

Un frammento di codice anti-sfarfallio nasconde la pagina (o parte di essa) utilizzando una regola CSS durante l'esecuzione dello script di test, per poi visualizzarla nuovamente. In questo modo si elimina l'effetto Flash visibile, ma il costo viene trasferito: la pagina viene visualizzata in un secondo momento per tutti gli utenti.

Il principio è semplice. Una riga di codice posizionata nella parte superiore del <head> applicato opacity: 0 O visibility: hidden A <body>. Quando lo strumento applica la variante, rimuove quella regola. Se lo strumento non risponde, un timeout massimo rivela comunque la pagina. I valori predefiniti sono generosi: il vecchio snippet di Google Optimize ha atteso fino a 4 secondi e lo SmartCode di VWO / Wingify imposta le sue tolleranze a 2000 ms per le impostazioni e 2500 ms per la libreria.

Questi dati sono significativi. Durante tutto questo tempo, non viene disegnato un singolo pixel. Un'analisi pubblicata da DebugBear sulla homepage di AdRoll ha mostrato un Largest Contentful Paint (LCP) di 6,0 secondi con la maschera abilitata, rispetto a 2,7 secondi una volta disabilitata la maschera. Google considera un LCP superiore a 2,5 secondi "da migliorare" e superiore a 4 secondi "negativo": una configurazione anti-sfarfallio inadeguata può trasformare una pagina altrimenti valida in un risultato negativo.

Tre regole per utilizzarlo senza danneggiarlo:

• Nascondi solo l'area testata (il blocco eroe, la forma), non il <body> intero. Il resto della pagina viene visualizzato normalmente e l'LCP viene influenzato solo se l'elemento nascosto è esso stesso l'elemento LCP.
• Riduci il tempo di timeout a 1000-1500 ms invece di 2000-4000 ms. Oltre a ciò, un visitatore che vede una pagina vuota viene penalizzato maggiormente rispetto a un visitatore che vede un'animazione lampeggiante.
• Abilita la maschera solo sulle pagine che ospitano un test. Un sistema anti-sfarfallio implementato su tutto il sito penalizza migliaia di pagine che non effettuano alcun test.

Misurare lo sfarfallio sul tuo sito: il metodo A/A'

Per determinare se lo sfarfallio influenza i tuoi test, esegui un test A/A': due gruppi visualizzano esattamente la stessa pagina, ma uno dei due riceve una modifica invisibile applicata dallo script di test. Qualsiasi differenza significativa tra i due gruppi misura il costo del meccanismo di iniezione stesso, indipendentemente da qualsiasi considerazione di marketing.

Un'operazione A/A standard non è sufficiente: nessun gruppo subisce alcuna modifica, quindi nessuno sperimenta lo sfarfallio. Questo è il metodo che raccomandiamo a BlastOptimize prima di avviare una serie di test su un nuovo sito o un nuovo modello di pagina.

Il protocollo in 4 fasi

1. Crea la variante A' Applica una modifica senza effetto visivo all'elemento che si intende testare (ad esempio, riscrivendo il testo del titolo con lo stesso testo o aggiungendo un attributo). data- (al pulsante). Il percorso tecnico è identico a quello di una vera variante.
2. Strumento il ritardo Annotare il tempo intercorso tra la prima visualizzazione (First Contentful Paint) e l'applicazione della modifica. L'estratto seguente è sufficiente.
3. Lascialo completare un ciclo intero (almeno 2 settimane per attenuare gli effetti dei giorni feriali/festivi) con il tuo solito obiettivo di conversione, come definito nel tuo configurazione obiettivo e tracciamento.
4. Leggi due numeri : il tempo mediano e il 90° percentile (visitatori lenti), quindi il divario di conversione tra A e A'.

<script>
// À appeler dans le code de la variante A', juste après la modification
(function () {
  var fcp = performance.getEntriesByName('first-contentful-paint')[0];
  var applique = performance.now();
  var delai = fcp ? Math.round(applique - fcp.startTime) : null;
  // delai > 0 : la variante s'applique APRÈS le premier affichage = flicker visible
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'flicker_delay', flicker_ms: delai });
})();
</script>

Come interpretare

• Ritardo negativo o nullo La variante viene applicata prima del primo rendering. Non è possibile alcuno sfarfallio.
• Ritardo mediano inferiore a 100 ms : sfarfallio raramente percepibile a livello cosciente, ma sufficiente per essere notato (ricordare i 13 ms). Monitorare il 90° percentile.
• Ritardo mediano superiore a 300 ms L'effetto sfarfallio è visibile alla maggior parte dei visitatori. Non eseguire alcun test su questa pagina finché l'integrazione non sarà stata corretta.
• Differenza di conversione significativa tra A e A' Il meccanismo di iniezione da solo ha un effetto misurabile. Tutti i test eseguiti su questo modello risentono di questa distorsione.

Questa cifra indica la dimensione minima dell'effetto che può essere interpretata in questa pagina. Se A/A' mostra -2% per A', una variante che guadagna +1,5% potrebbe in realtà guadagnare +3,5%, e una variante a -1% potrebbe essere neutra.

9 correzioni concrete, dalle più redditizie alle più costose

La maggior parte degli sfarfallii può essere risolta senza cambiare strumenti: spostando lo script, schiarendolo e codificando le varianti in CSS anziché in JavaScript. Ecco le leve, classificate in base al rapporto sforzo/beneficio.

1. Posiziona il frammento nella parte superiore del <head>, prima dei CSS e di altri script di terze parti. Risultato immediato, cinque minuti di lavoro.
2. Esci dallo script di test in Google Tag Manager. Integralo in modo permanente nel template. La differenza di 400 ms misurata da Simo Ahava deriva proprio da questo.
3. Aggiungi un preconnect al dominio che serve lo script (<link rel="preconnect" href="…">) per aprire la connessione ancor prima che il browser incontri il tag.
4. Codifica le modifiche visive utilizzando CSS. Una regola CSS iniettata nel <head> si applica non appena l'elemento viene disegnato, senza attendere che esista nel DOM. Cambia un colore, nascondi un blocco o riordina due elementi con order L'utilizzo di Flexbox non richiede JavaScript. Questa è anche la raccomandazione presente nella documentazione. Optimizely sulle varianti che lampeggiano.
5. Pulisci il codice generato da editor visuale : rimuovere i selettori ridondanti, raggruppare le modifiche sullo stesso elemento, evitare di riscrivere completamente i blocchi HTML quando è sufficiente una modifica del testo.
6. Archivia i test completati. Ogni test in pausa che rimane nella configurazione aumenta la dimensione del file per tutti i visitatori.
7. Nascondi solo l'area testata., con un timeout breve (1000-1500 ms), anziché l'intera pagina per 4 secondi.
8. Evitate di eseguire test di reindirizzamento su pagine con un elevato traffico in entrata. Il reindirizzamento all'URL B dopo il caricamento dell'URL A comporta due caricamenti di pagina: questa è la forma più dispendiosa di flicker.
9. Distribuisci lo script da una CDN vicina ai tuoi visitatori, con una configurazione limitata ai soli test attivi sulla pagina visitata. Questa è la leva su cui hai meno controllo, poiché dipende dallo strumento: chiedi al tuo fornitore o consulta la nostra pagina sulla distribuzione degli script BlastOptimize il più vicino possibile al visitatore.

Quando passare al lato server

I test lato server eliminano per impostazione predefinita lo sfarfallio: il server sceglie la variante e invia direttamente l'HTML corretto; nessuno script riscrive la pagina nel browser. Lo svantaggio è ben noto: ogni test passa attraverso uno sviluppatore, l'editor visuale diventa inutilizzabile e il ciclo di iterazione si allunga. I test lato server sono giustificati per i test su elementi strutturali (algoritmo di prezzo, processo di checkout, navigazione), per le pagine in cui anche la minima deviazione nel LCP è costosa, o quando l'analisi A/A rivela un bias che le nove correzioni menzionate in precedenza non risolvono. Per i test di titoli, elementi visivi o pulsanti, un approccio lato client ben integrato rimane più veloce da implementare. Questa scelta architetturale merita una guida a parte, che dedichiamo ai test lato server.

Lista di controllo anti-sfarfallio prima di ogni lancio

Prima di avviare un test in produzione, verifica questi dieci punti. Anche un solo "no" sui primi quattro è sufficiente per posticipare il lancio.

• ☐ Il frammento è codificato direttamente nel <head>, in prima posizione tra gli script, esclusi i gestori di tag.
• ☐ La modalità di caricamento (sincrona/asincrona) è nota e documentata per questa pagina.
• ☐ La variante è stata verificata su uno smartphone reale con la rete limitata a "4G lento" negli strumenti di sviluppo.
• ☐ Viene misurato il ritardo tra la prima visualizzazione e l'applicazione della variante (mediana e 90° percentile).
• ☐ Le modifiche visive vengono effettuate tramite CSS ove possibile.
• ☐ Se si utilizza la maschera, questa si applica all'area testata e il suo timeout è ≤ 1500 ms.
• ☐ È stato confrontato il LCP della pagina con e senza test (differenza target: inferiore a 100 ms).
• ☐ I test completati sono stati archiviati dall'account.
• ☐ Nessun test di reindirizzamento viene avviato su una pagina di ingresso principale senza una valida ragione.
• ☐ Su questo modello di pagina è stato eseguito un test A/A negli ultimi 6 mesi.

Flickr viene aggiunto all'elenco di errori comuni nei test A/B che invalidano un test ancor prima dell'analisi statistica. È tanto più pericoloso su test multivariati, dove diverse aree vengono modificate simultaneamente e dove ogni combinazione può produrre un flash diverso, e sulla siti di e-commerce, dove le pagine dei prodotti caricano molte immagini e script di terze parti.

FAQ

L'effetto flickering ha un impatto sulla SEO?

Indirettamente, sì. Il flickering di per sé non è una penalizzazione, ma le soluzioni implementate male sì: un anti-flicker che oscura la pagina degrada il LCP (Low Page Content), e una variante che inserisce blocchi aumenta il CLS (Cumulative Layout Shift). Entrambe queste metriche fanno parte dei Core Web Vitals considerati da Google. Confronta i dati del campo di Search Console su pagine testate e non testate per verificarlo.

Il mio strumento dichiara di essere "privo al 100% di sfarfallio": posso crederci?

Chiedi come. "Senza sfarfallio" spesso significa "con mascheramento": il flash scompare, ma la pagina si carica più tardi. Controlla tre cose: il metodo di caricamento dello snippet, il valore di timeout del mascheramento e la differenza LCP misurata con e senza lo script. Un test A/A risolve la questione sul tuo sito. Troverai le differenze di approccio nel nostro comparativo BlastOptimize / Kameleoon e nel nostro su con AB Tasty.

Un frammento di codice sincrono rallenta davvero il mio sito?

Ritarda la visualizzazione iniziale del tempo di download ed esecuzione dello script. Con un file di piccole dimensioni servito da una CDN, la differenza è di poche decine di millisecondi. Con un file di grandi dimensioni o un server lento, si parla di centinaia di millisecondi e un'interruzione del servizio del provider può bloccare la pagina fino al timeout di rete. Misurate il LCP con e senza lo snippet prima di decidere.

Posso caricare il mio strumento di test A/B tramite Google Tag Manager?

Tecnicamente sì, ma questa configurazione produce il maggior sfarfallio perché GTM carica i suoi tag in modo asincrono. Le misurazioni pubblicate mostrano circa 400 ms di mascheramento aggiuntivo rispetto a un'integrazione diretta. Riserva GTM per attivare gli eventi di tracciamento, non per lo script che modifica la pagina.

I banner di consenso peggiorano lo sfarfallio?

Sì, è possibile. Se il tuo strumento di test si carica solo dopo l'accettazione dei cookie, o se la piattaforma di gestione del consenso blocca gli script mentre legge la scelta del visitatore, l'applicazione della variante verrà ritardata di conseguenza. Verifica l'ordine di esecuzione tra il banner e lo snippet di test in una sessione pulita, senza cookie.

Punti chiave

• L'effetto flicker consiste nella visualizzazione temporanea della pagina originale prima della variante. È una caratteristica specifica dei test lato client.
• Non si tratta di un semplice difetto visivo: esso falsa sistematicamente il confronto, poiché ne è affetto solo uno dei due gruppi.
• Le cause principali sono uno script posizionato in modo errato, un passaggio attraverso GTM, il caricamento asincrono, un file troppo grande e varianti codificate in JavaScript anziché in CSS.
• La funzione anti-sfarfallio maschera il sintomo ma ritarda la visualizzazione: selezionare l'area da testare e mantenere un timeout ≤ 1500 ms.
• Misurare prima di correggere: il test A/A' fornisce il costo reale del meccanismo di iniezione nel vostro sito.
• Il lato server elimina lo sfarfallio per impostazione predefinita, a costo di una dipendenza dagli sviluppatori.

Vuoi vedere come BlastOptimize serve le sue varianti? Dai un'occhiata al nostro offerte e prezzi per avviare un test A/A iniziale sul tuo sito.