Flicker effect

Parce que le test s’exécute côté navigateur.

La page se charge normalement. Le script de test s’exécute ensuite, décide de la variante et modifie l’affichage. Entre les deux, la version d’origine est visible pendant quelques dizaines à quelques centaines de millisecondes.

Plus le script arrive tard, plus le scintillement est long. Un script chargé après les autres ressources produit un effet nettement perceptible.

Trois choses, et la troisième invalide le test.

L’expérience. Une page qui change est perçue comme cassée, ce qui augmente la charge cognitive au pire moment.

La mesure du temps d’affichage. Le Largest Contentful Paint se dégrade sur les deux variantes, et le déplacement d’éléments alimente le Cumulative Layout Shift.

La validité du test. Les visiteurs de la variante subissent un scintillement que ceux du groupe témoin n’ont pas. La différence mesurée inclut alors l’effet du scintillement, pas seulement celui du changement testé.

Trois, par robustesse croissante.

Masquer la page pendant l’exécution. Un voile blanc couvre le contenu jusqu’à ce que la variante soit appliquée. Le scintillement disparaît, remplacé par un délai d’affichage. C’est un compromis, et il faut plafonner la durée du masque pour éviter une page blanche si le script échoue.

Charger le script en premier, en synchrone dans l’en-tête. Cela réduit le scintillement et retarde l’affichage général.

Tester côté serveur. La variante est décidée avant l’envoi de la page, et le navigateur reçoit directement la bonne version. Aucun scintillement, un coût de mise en œuvre nettement supérieur.

Que le scintillement a été mesuré, pas supposé absent.

Un test dont la variante affiche un temps de chargement dégradé mesure deux choses à la fois. Le résultat est alors inexploitable, quelle que soit sa signification statistique.