Wer mit A/B-Testing zu tun hat, kennt sicherlich den Flicker Effekt bereits. Für alle anderen soll dieser Artikel alle Fragen zum Thema “Flickering” beantworten.

Fangen wir vorne an. Um zu erläutern was der Flicker-Effekt ist, sollte man den groben Hintergrund zur Funktionsweise von <tag>-basierten Testingtools kennen.

Die meisten auf dem Markt erhältlichen A/B-Testingtools sind von ihrer Funktionsweise <tag>-basiert. Mit anderen Worten: Das Testingtool wird durch einen (oder mehrere) JavaScript-Tags in die Testumgebung integriert. Hierbei handelt es sich also um einen Eingriff in das Frontend (HTML) der Website. Der Vorteil dieser Methode: Sie ist wenig invasiv. Häufig ist die Integration mit nur einem JavaScript Schnippsel abgeschlossen.

Wird die Seite geladen, erfolgt an dieser Stelle eine Anfrage an den Server des Tool-Anbieters. Dort wird entschieden, ob die Seite Bestandteil eines Tests ist und liefert entsprechend je nach Tool JavaScript, CSS und/oder HTML zurück. Dieses wird in die Seite integriert und von dieser zusätzlich interpretiert. Der Nutzer erhält damit je nach Test und Testgruppe eine Veränderung oder eben die Kontrollversion.

Was ist der Flicker Effekt?

Beim Flicker-Effekt sieht der Nutzer – meist für einen Sekundenbruchteil – den original Inhalt der Seite, bevor dieser durch die Testvariante ausgetauscht wird. Im schlimmsten Fall handelt es sich dabei nicht nur um einen Bruchteil, sondern um ein paar Sekunden, bis sich die Seite “umbaut”. In der Regel wird dies allgemein von Nutzern ohne Kenntnis über die Testsituation als Flackern empfunden.

Am häufigsten wird der Effekt im Sichtbereich (“above the fold”) wahrgenommen – besonders bei Websites die per se schon nicht besonders schnell laden. Es gibt Anbieter, die diesen Effekt umgehen, in dem sie das Weiterladen der Seite an dieser Stelle blockieren. Hier flackert dann die Seite zwar nicht, lädt aber länger, was ebenso einen negativen Effekt haben kann.

Wodurch entsteht das Flackern?

Die Eingangs beschriebene Funktionsweise im Hinterkopf kann der Flicker-Effekt zusammengefasst zwei unterschiedliche Ursachen haben.

1. Technische Ursache

Einige Tools lassen sich sowohl als synchrones- wie auch asynchrones JavaScript einbinden. Letzteres hat – rein technisch – den Vorteil, dass das Script den Ladevorgang der Seite nicht beeinflusst (“non blocking JavaScript”). Was aus technischer Sicht ein Vorteil ist, ist leider gleichzeitig der perfekte Nährboden für den Flicker Effekt: Die Seite kann völlig unabhängig vom Testingtool weiter laden.

Mit anderen Worten: Während die Website lädt und Inhalte dargestellt werden, wird parallel dazu die Anfrage an den Server des Tools gestellt. Dieser liefert ohne Abhängigkeit zum Zustand der Originalseite “irgendwann” ein Ergebnis zurück. Je schneller jetzt die Website lädt, desto größer wird der Flicker Effekt. Besonders im weiteren Verlauf einer Nutzersession spielt das eine Rolle, weil hier Teile der Website bereits im Cache des Browsers liegen und somit noch schneller geladen werden können (z. B. Grafiken und CSS).

Eine weitere – sehr häufige – Ursache ist die Position der Integration des <tags> im Quellcode der Website. Je später das Tool die Möglichkeit erhält, die Anfrage zu bearbeiten und ein Ergebnis zurück zuliefern, desto mehr kann der Nutzer bereits von der Originalseite gesehen haben.

Die bereits genannten Ursachen lassen sich noch beeinflussen, die Funktionsweise des Tools und Reaktionszeit des Servers jedoch nicht. Wartet das Testingtool per se auf die Fertigstellung des Dokumentenbaums (sog. DOM – Document Object Model – also praktisch das Inhaltsverzeichnis eines Dokuments), bevor es aktiv wird (sog. DOM-Ready), so ist ein flackern praktisch unausweichlich.

Das gleiche gilt für Reaktions- und Antwortzeit des Tools. Sind die Server langsam, steht kein CDN (Content Delivery Network) – zum Beispiel in Europa – zur Verfügung oder sind diese überlastet, so entsteht auch hierdurch eine Verzögerung und damit ein flackern.

2. Die Testumsetzung

Neben technischen und Tool abhängigen Ursachen kann eine weitere die Testumsetzung selbst sein. Generell gilt: Je mehr JavaScript beim Test verwendet wird, desto länger dauert die Testausspielung.

Nicht nur wegen der Menge an Code, die zusätzlich in die Seite geladen wird, vor allem aber durch die Interpretationszeit des Browsers. Um Manipulation an bestehenden HTML-Code vornehmen zu können, muss auf die Fertigstellung des Dokumentenbaums gewartet werden. Erst danach kann der Inhalt angesprochen und verändert werden.

Während nun das vom Testingserver zurück gelieferte JavaScript die zu testende Seite manipuliert, hat der Browser bereits (angefangen) das Dokument zu rendern, oder ist evtl. schon fertig. Hier wird dann der Austausch alt gegen neu sichtbar.

Auch die Inhalte selbst spielen eine Rolle. Werden zum Beispiel Inhalte mit hoher Aufmerksamkeit ausgetauscht, so fällt dies besonders leicht auf (z. B. das Produktbild auf einer Produktseite). Gerade bei großen Elementen im direkten Sichtbereich (Keyvisuals, Hero-Shots oder Hintergrundbilder) fallen häufig Flicker-Effekte verstärkt auf.

Letztlich hat auch die Dateigröße der nachgeladenen Inhalte Einfluss auf die Darstellungszeit und somit auf das flackern. Große Bilder mit entsprechend hoher Dateigröße laden langsamer und führen ggf. zu einem sichtbaren “nachladen”.

Neben der Umsetzung selbst kann auch die Performance der Originalseite Einfluss auf das Flackern nehmen.

• Rendert die Seite generell sehr langsam (“schlechtes HTML”, langsamer Webserver),
• ist der Quellcode nicht gut strukturiert (keine oder wenige eindeutige Identifier),
• ist die Seite sehr groß (weißt besonders viele Elemente auf) oder,
• werden sehr viele Assets geladen (JavaScripts, Bilder etc.)

so kann auch dass den Effekt verstärken.

Wie kann man das Flackern vermeiden?

<html>
  <head>
     ... Quellcode des Headers ...

     <tag>-basiertes Testingtool

  </head>
  <body>

     ... Originalinhalt der Website ...

  </body>
</html>

Um die technischen Ursachen einzuschränken, sollte das Tool möglichst im Dokumentkopf, am besten vor dem schließenden </head>-Tag integriert werden. Einige Toolanbieter empfehlen sogar die Integration noch früher. Unserer Erfahrung nach ist das nicht empfehlenswert, weil hier ggf. benötigte Scripte der Originalseite innerhalb des Tests nicht verwendet werden können (z. B. JavaScript Bibliotheken, PlugIns etc.). Auch das CSS der Seite lässt sich hierbei nur unnötig umständlich verändern.

Eine weitere Maßnahme gegen flackern ist entgegen der “technisch optimalen” asynchronen eine “klassische” synchrone Integration zu verwenden. Die Toolanbieter sichern in der Regel eine hohe Serverzuverlässigkeit von 99.9% zu, so dass hier der Kritikpunkt (häufig aus Richtung IT)

“der Server des Toolanbieters kann evtl. nicht erreichbar sein – unsere Seite lädt dann nicht fertig”

im akzeptablen Rahmen liegt. Einzig die Ladezeit des Dokuments wird erhöht, weil das JavaScript des Tools + der Testcode zusätzlich zur Seite geladen werden.

Übrigens gilt beides auch für alle externen Scripte, die außerhalb des eigenen Webservers liegen (z. B. Analytics, Kampagnentracking, Advertising etc.)

Unserer Erfahrung nach birgt die asynchrone Integration hingegen ein zusätzliches Risiko: Die Anbieter müssen aufgrund des parallel ladenden Scripts – also unabhängig vom Zustand der Originalseite – mit sog. Timeouts arbeiten. Diese Timeouts sorgen dafür, dass das Laden irgendwann abgebrochen wird, sollte dieses nicht in einem definierten Zeitraum erfolgen (in der Regel 2 – 2,5 Sek). So kann beim Laden der Seite, z. B. bei einer etwas länger ladenden (große Kategorieseite), der Nutzer unter Umständen aus dem Test fliegen.

Was die Testumsetzung angeht: Hier gilt es möglichst auf JavaScript zu verzichten. Bei Änderungen am Layout sollte so viel es geht über CSS realisiert werden. Dieses “greift” sofort, ist unabhängig vom DOM-Ready und muss nicht erst noch von einer nachgelagerten Instanz (JavaScript Interpreter des Browsers) verarbeitet werden.

Bei inhaltlichen Änderungen kommt man nicht am JavaScript vorbei – hier gilt: Möglichst effizient arbeiten.

“Viele Wege führen nach Rom, aber nicht alle sind gleich schnell.”

Eine weitere Möglichkeit ist “hide early”. Gerade wenn die Verarbeitung des JavaScripts zu lange dauert bietet sich diese Vorgehensweise an. Hierbei wird beispielsweise der Inhaltsbereich (schnell) per CSS ausgeblendet und direkt nach der abgeschlossenen Verarbeitung des JavaScripts (später) wieder eingeblendet. Dies lässt sich durch eine Ladeanimation und “softes” Einblenden zusätzlich “verschleiern”.

Mit diesen Tricks wird zwar die Ladezeit des Tests nichts verbessert, aber zumindest das Flackern minimiert und die User Experience nicht verschlechtert.

Damit wären wir auch schon bei der Überleitung zur letzten Frage.

Welche Auswirkungen hat der Flicker-Effekt auf die Testergebnisse?

Die (negative) Beeinflussung der User Experience ist die größte Gefahr beim Flicker Effekt. Dabei spielt es weniger eine Rolle, dass Nutzer mitbekommen, Teilnehmer eines Tests zu sein. Viel mehr wird die Seite unter Umständen als langsam(er) empfunden, was eine Verschlechterung im Vergleich zur Kontrollversion bedeutet. Auf das Thema Ladezeit und dessen Einfluss auf die Conversion Rate gehe ich in meinem Artikel “So verbrennt Ihr HTML Code >1 Mio € Umsatz pro Jahr” genauer ein.

D. h. es bestehen nicht mehr gleiche Bedingungen zwischen Version A und B im Test. Letztere ist benachteiligt. Insofern müsste man sich die Frage stellen, wie zuverlässig überhaupt die Messergebnisse sind.

Ist B schlechter stellt sich die Frage: Liegt das an der langsamen Test-Performance oder an der -Hypothese. Die Gefahr hierbei: Man wirft ein Testkonzept in die Tonne, welches evtl. gar nicht schlecht sondern nur aufgrund des Setups nicht wie gewünscht funktioniert hat.

Umgekehrt, liegt B vorne – wenn auch nur leicht – könnten die Ergebnisse noch besser aussehen, wenn die Bedingungen bei beiden Versionen gleich (schnell) gewesen wären?

Entgegen des erst kürzlich veröffentlichen Artikel des Testingtool Anbieters Monetate zum Thema “The FUD Behind Web Page Flicker” sehe ich hier durchaus Bedarf zur Diskussion. Im Artikel heißt es:

“Simply put, your website visitors are the ones who should tell you what’s a good experience and what’s a bad experience. By running a few simple tests, it may turn out that flicker doesn’t affect the customer experience at all―or that it actually helps it by way of emphasizing the change or experience you want visitors to see.”

Meines Erachtens liegt genau hier die Gefahr. Es ist nicht besonders wissenschaftlich nach ein paar Tests davon auszugehen, dass sich Nutzer “trotz flackern” nicht davon beeinflussen lassen (positiv wie negativ).

Um für die eigene Website und deren Nutzer eine qualifizierte Aussage treffen zu können, müsste man tatsächlich die Wirkung des Flicker Effekts explizit testen. Um beispielsweise ein sauberes Testszenario zu gewährleisten, müsste die Kontrollversion gegen eine Veränderung mit und ohne Flackern getestet werden.

Fazit

So lange man nicht im Rahmen eines eigenen Tests für seine Nutzer beweisen kann, dass der Flicker-Effekt keinen negativen Einfluss auf die “Testuser Experience” hat, gilt es das flackern zu vermeiden. Zumindest soweit es die technischen Möglichkeiten zulassen. Wenn es um die Verbesserung der Conversion Rate und den Umsatz geht, gilt eben nicht “im Zweifel für den Angeklagten” sondern “sicher ist sicher”.

Zusammengefasst:

• synchrones Integrationsskript vor dem schließenden -Tag einfügen
• möglichst CSS anstatt JavaScript einsetzen
• beim Einsatz von JavaScript effizient bleiben und möglichst performante Methoden einsetzen
• auf die Größe der Änderungen achten: Stichwort Dateigröße
• lässt sich das Flackern nicht vermeiden, dieses so gut es geht mit aus- und einblenden verbergen

Weiterführende Links

• “5 Tipps für Testing – die jeder Conversion Engineer kennen sollte
• “So verbrennt Ihr HTML Code >1 Mio € Umsatz pro Jahr”
• “The FUD Behind Web Page Flicker”