Effetto sfarfallio

L'effetto flicker, detto anche flash del contenuto originale, è il breve istante durante il quale un visitatore vede la versione di controllo di una pagina prima che uno script di test lato client la sostituisca con la variante. Questo accade perché il browser renderizza il markup originale non appena arriva, mentre la libreria di test è ancora in fase di caricamento, inizializzazione, decisione su quale variante applicare e applicazione delle modifiche. Il risultato è un lampo visibile: il testo cambia, gli elementi si spostano, le immagini si scambiano e la pagina si stabilizza nel suo stato finale dopo che il visitatore ha già iniziato a leggere.

Lo sfarfallio non è un fastidio estetico, bensì una fonte di errore di misurazione. I visitatori del gruppo che utilizza la variante sperimentano un'interruzione improvvisa che i visitatori del gruppo di controllo non vedono mai, quindi i due gruppi ricevono esperienze diverse in un modo che non ha nulla a che vedere con il design in fase di test. Una parte dei visitatori del gruppo che utilizza la variante abbandona la pagina durante o immediatamente dopo lo sfarfallio, e alcuni sono talmente distratti che il loro comportamento successivo risulta diverso. Questo distorce i risultati a sfavore della variante, il che significa che i miglioramenti reali non vengono rilevati e il programma di test sottovaluta sistematicamente il valore delle modifiche che valuta.

La soluzione standard consiste in uno snippet anti-sfarfallio, che nasconde il corpo della pagina finché lo script di test non ha terminato di applicare le modifiche, per poi visualizzarlo nuovamente. Questo comporta uno sfarfallio visibile in cambio di una schermata vuota, un compromesso vantaggioso solo se lo script si carica rapidamente. Se la libreria di test è lenta o non si carica affatto, il timeout dello snippet determina per quanto tempo i visitatori rimangono a fissare il vuoto prima che il contenuto originale venga visualizzato. I timeout vengono spesso impostati sui valori predefiniti di due o quattro secondi, il che, su una connessione mobile lenta, significa che la soluzione anti-sfarfallio comporta un costo maggiore in termini di conversioni rispetto allo sfarfallio che previene.

Una corretta implementazione si basa quindi sulla sequenza e sulla velocità, piuttosto che sul singolo frammento di codice. Lo script di test dovrebbe essere caricato in modo sincrono dall'intestazione del documento, in modo da iniziare il prima possibile, idealmente da un endpoint veloce e ben configurato, piuttosto che da uno condiviso. Il timeout anti-sfarfallio dovrebbe essere impostato in modo aggressivo, in genere ben al di sotto di un secondo, in modo che un errore si traduca in un breve lampeggio anziché in una schermata vuota prolungata. Le modifiche alle varianti dovrebbero essere applicate tramite lo scambio di classi CSS, ove possibile, piuttosto che manipolando singolarmente molti elementi. I test che richiedono una riscrittura strutturale significativa sono meglio implementati lato server piuttosto che forzati attraverso uno strumento lato client.

Per diagnosticare il flickering è necessario analizzare le condizioni reali, non la macchina di uno sviluppatore. Profili di rete con limitazione della larghezza di banda, dispositivi mobili di fascia media e dati di monitoraggio degli utenti reali rivelano l'esperienza effettiva del pubblico. La discrepanza nel rapporto di campionamento è il segnale indiretto più forte: se i visitatori vengono persi durante l'inizializzazione dello script, la suddivisione del traffico non corrisponderà all'allocazione configurata e questo controllo dovrebbe essere eseguito in ogni test, indipendentemente dal fatto che si sospetti o meno il flickering.

Misurare lo sfarfallio anziché presumerne l'assenza è semplice, ma raramente viene fatto. Registrare il caricamento di una pagina su una connessione con velocità limitata e analizzare i singoli fotogrammi mostra esattamente cosa vede un visitatore e per quanto tempo; tuttavia, eseguire questa operazione su un dispositivo di fascia media anziché su una macchina di sviluppo produce solitamente risultati poco soddisfacenti. Una seconda complicazione, sempre più frequente, è l'interazione tra gli script di test e le piattaforme di gestione del consenso, poiché entrambi competono per l'esecuzione e possono bloccare il rendering. Quando lo strumento di gestione del consenso viene caricato prima dello strumento di test, l'applicazione della variante viene ritardata fino alla risoluzione del consenso, il che può aggiungere un secondo o più e si applica in modo non uniforme nelle diverse regioni con requisiti di consenso differenti. È necessario sequenziare deliberatamente queste due dipendenze e misurarne l'effetto combinato sul rendering prima di poter trarre conclusioni attendibili sulle prestazioni di una variante.

Il problema di fondo è che uno strumento di test è una dipendenza aggiuntiva inserita nel percorso di rendering critico di ogni pagina. La gestione di tale dipendenza fa parte di prestazioni web lavoro piuttosto che qualcosa che il team di ottimizzazione può risolvere da solo e le due discipline devono essere coordinate. Laddove lo sfarfallio non può essere controllato in modo accettabile, la risposta appropriata entro un Servizio CRO L'obiettivo del programma è spostare gli esperimenti interessati all'implementazione lato server, anziché accettare un pregiudizio permanente e invisibile nei confronti di ogni variante testata dal programma.