A/B-Testing: Wie unsere neue Technologie dem Flicker-Effekt ein Ende setzt

Wir haben vor wenigen Wochen eine Innovation angekündigt, die die kleine Welt des A/B-Testing aufgerüttelt hat. Wir haben ein Problem mit schwerwiegenden Konsequenzen behoben: den Flicker-Effekt.

Wir sind froh, dass diese Innovation so viel von sich reden macht. Unsere Kunden haben uns sehr positives Feedback zu unserer neuen Technologie gegeben, die automatisch auf ihren Webseiten angewendet wird und von deren Vorteilen sie damit sofort profitieren konnten. Auch andere Marktbegleiter haben sich die Zeit genommen, ihre Analysen und Kommentaren zu teilen.

Allerdings scheint es nötig, Missverständnisse aus dem Weg zu räumen. Und das möchten wir tun. Deshalb hier einige Erklärungen, wie unsere 100% flickerfreie Technologie funktioniert.

100% flickerfrei: Geht das wirklich?

Kurz vorweg: Ein Flicker-Effekt ist, wenn ein Besucher auf einer A/B-getesteten Seite landet und die Referenzversion vor der Variante sieht.

Kameleoon bleibt dabei: Seine neue 100% flickerfreie Technologie ist eine Innovation, die alle Flicker-Probleme auf Ihrer Webseite beseitigt!

In einem Punkt sind sich alle Experten einig: Der Flicker-Effekt wird von A/B-Tests erzeugt. Alle A/B-Testing-Tools haben Best Practices entwickelt, um den Effekt einzudämmen. Wir wollten weiter gehen und haben entschieden, das Übel an der Wurzel zu packen und es ein für alle Mal zu beseitigen. Auch wenn einige das für unmöglich halten, wir wollten uns nicht mit der Situation zufrieden geben, sondern eine innovative Lösung für ein Problem finden, das allen bekannt ist.

„Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie sich wahrscheinlich schnellere Pferde gewünscht“ – Henry Ford, Gründer der Ford Motor Company

1 Wie entsteht der Flicker-Effekt?

Es gibt zwei Ursachen für den Flicker-Effekt. Diese Vorbemerkung ist von entscheidender Bedeutung, um die Arbeitsweise unserer neuen absolut flickerfreien Technologie zu verstehen.

A. Auf Seiten der User: Was Sie tun können

Die erste mögliche Ursache des Flicker-Effekts ist das Skript selbst – und der Zeitpunkt, zu dem es bereit ist und die Änderungen auf Ihren Webseiten möglich macht.

Die von verschiedenen A/B-Testing-Lösungen vorgeschlagene Best Practice geht vor allem in diese Richtung (Vorsicht, alle Tipps sind nicht unbedingt relevant, wie wir am Ende dieses Artikels darlegen werden!).

Wir erzählen Ihnen nichts Neues: je früher das A/B-Testing-Skript bereitsteht, desto kleiner ist das Risiko eines Flicker-Effekts. Mehrere Faktoren beeinflussen diese erste Ursache (besonders die beiden ersten Punkte, die mit der Integrationsmethode des Skripts in den Code Ihrer Seite zusammenhängen):

• Fest in Ihren HTML-Code einprogrammiertes Skript vs. Integration durch einen Tag-Manager
• Position des Skripts auf der Seite und bzgl. anderer Ressourcen (oben, unten…)
• Gewicht des Skripts und Performance des Servers (je leichter das Skript und je leistungsstärker der Server, desto schneller wird das Skript durch den Browser des Besuchers geladen)
• Caching-Kapazitäten des Browsers

Synchrones oder asynchrones Skript: was ist besser? Man hört viel von synchronem und asynchronem Skript, von ihrem Einfluss auf das Laden Ihrer Seiten und auf den Flicker-Effekt.

Bei synchronem Skript blockiert der Browser die Durchführung und das Display der Seite, solange das Skript nicht geladen und einsatzbereit ist. Das kommt daher, dass der Browser den Anweisungen des Skripts Vorrang gibt. Er will sie vor allen anderen Aktionen ausführen und ist blockiert, solange das Skript nicht geladen ist.

Das hat eine logische Konsequenz: Solange das Skript nicht geladen ist, sieht man eine weiße Seite. Und wenn hinzukommt, dass der Server des Skripts nicht antwortet, dauert der Effekt „Weiße Seite“ an, und die Webseite ist nicht zugänglich. Wer möchte schon, dass so etwas auf seiner Webseite passiert? Dennoch ist die Nutzung von synchronem Skript eine von bestimmten Playern empfohlene „Best Practice“ – und einige ihrer Kunden hatten das Problem. Oops…

Asynchrones Skript wird gleichzeitig mit anderen Ressourcen geladen. Eine Blockierung ist damit ausgeschlossen. Allerdings haben Sie nicht die Garantie, dass das Skript vor dem Rest der Elemente der Seite bereit ist. Und das kann zum Flicker-Effekt führen, weil zu verändernde Elemente erscheinen können, bevor das Skript geladen ist.

Vor vier Jahren haben wir die sogenannte „asynchrone blockierende Integration“ entwickelt, eine Methode, die den bestmöglichen Kompromiss zwischen synchron und asynchron sucht. Das Skript wird asynchron aufgerufen, aber die Seite bleibt weiß, solange es nicht zugänglich ist, oder solange ein bestimmter Zeitraum (z.B. eine Sekunde) nicht abgelaufen ist. Also hat man einerseits die Vorteile des synchronen Skripts (weiße Seite), aber mit einer zusätzlichen Sicherheit: Sollte der Kameleoons Server (CDN) nicht antworten, lädt die Seite trotzdem, wenn die Sekunde abgelaufen ist.

Ergebnis: eine Performance, die der des synchronen Skripts in Sachen Flicker-Effekt entspricht, mit zusätzlicher Sicherheit. Immer schon haben wir Tipps und Best Practices an unsere Kunden weitergegeben, und auch in diesem Bereich treiben wir die Innovation voran.

B. Auf Seiten des A/B-Testing-Tools: Was das Tool leisten muss

Die zweite Ursache des Flicker-Effekts ist die Interaktion zwischen Ihrem A/B-Testing-Tool und der Webseite bei der Umsetzung der Änderungen. Auch wenn das Skript der Seite geladen ist und bereitsteht, besteht das Risiko eines Flicker-Effekts weiter. Die Faktoren, die hier einwirken sind vor allem die Qualität des Software-Codes und der benutzten Technologie: Die A/B-Testing-Lösung sollte so wenig CPU und RAM wie möglich benutzen und gleichzeitig so schnell wie möglich mit den entsprechenden Elementen auf der Seite interagieren.

Unsere neue 100% flickerfreie Technologie kümmert sich natürlich um diese zweite Ursache, und nicht, wie ein Konkurrent fälschlicherweise annahm, um die Problematik der Skripteinstellung (die asynchrone blockierende Methode – die wir schon seit Jahren anwenden).

Eine neue 100% flickerfreie Technologie ohne zusätzliche Einstellungen, kompatibel mit 92% der Browser.

Wir sind viel weiter gegangen. Unsere Technologie setzt bei der Interaktion von Kameleoon mit den Elementen Ihrer Seite an, wenn das Skript zugänglich ist. So wird das Problem der Aktualisierungszyklen des Browsers gelöst: Die Änderungen werden an den entsprechenden Elementen vorgenommen, sobald sie auf der Seite erscheinen, ohne „weiße Seite“ und ohne „Absturz“ Ihrer Seite.

Für die Technikexperten unter Ihnen: Unsere Technologie basiert auf DOM Mutation Observern, wie einige von Ihnen richtig erkannt haben und in ihren Reaktionen auf unsere Ankündigung bemerkt haben (nicht schlecht, bravo!). Es handelt sich um einen Standard, der in allen von Kameleoon unterstützten Browsern (Desktop und Mobile) implementiert wird, außer IE9 und 10 – die auch sonst problematisch sind, aber das ist hier nicht das Thema.

Die neue flickerfreie Technologie ist also mit 92% der gängigen Browser kompatibel.

Darüber hinaus sind keine weiteren Einstellungen nötig, um von der neuen Technologie zu profitieren. Und wenn ein Browser nicht kompatibel ist, wird die flickerfreie Technologie einfach nicht eingestellt. Ihre Varianten funktionieren störungsfrei. Das Risiko des Flicker-Effekts besteht in diesem Fall weiter, aber nicht mehr (eher weniger) als bei anderen A/B-Testing-Tools.

Kurzum: Die neue 100% flickerfreie Technologie steigert Ihre Performance, ohne negative Nebenwirkungen!

2 Welche Rolle spielt die Best Practice?

Die Performance der innovativen Technologie, die wir entwickelt haben, ermöglicht, den Flicker-Effekt komplett auszuschalten. Allerdings müssen einige Best Practice-Regeln befolgt werden. Sie sind weitestgehend bekannt, auch bei unseren Mitwettbewerbern. Einige möchten wir allerdings korrigieren.

Um den Flicker-Effekt weitestgehend zu vermeiden, sollten Sie:

• Das Skript so weit oben wie möglich im Header Ihrer Seite integrieren.
• Das Skript mit der asynchronen blockierenden Methode einstellen (siehe oben). Wenn Ihre Lösung nicht diese Möglichkeit bietet, empfehlen wir im Gegensatz zu bestimmten Konkurrenten nicht die synchrone Methode. Sie vermindert zwar das Flicker-Risiko im Vergleich zur asynchronen Methode, nicht aber zur asynchronen blockierenden Methode. Vor allem aber besteht die (kleine, aber dennoch reelle) Gefahr, dass Ihre gesamte Webseite abstürzt.
• Keine Tag-Manager benutzen, um die Lade-Reihenfolge der unterschiedlichen Skripte beeinflussen zu können.
• Das Gewicht des Skripts reduzieren. Kameleoon hat bereits vor einigen Jahren ein Pre-Processing entwickelt, das das Skript beschleunigt, indem nur das Nötigste geladen wird. Wenn Ihr A/B-Test kein Advanced Targeting benötigt, werden die entsprechenden Targeting-Kriterien auch nicht geladen.
• Die Ladezeit Ihrer Webseite im Ganzen und aller Elemente optimieren.
• Ein CDN benutzen, um die Ladedauer Ihres Skripts zu beschleunigen.
• Auf keinen Fall Tests mit Weiterleitung durchführen. Eine Weiterleitung durch ein A/B-Testing-Tool kann leider nur über JavaScript vorgenommen werden. Im Gegensatz zu einer „echten“ Weiterleitung (z.B. http 302), die sehr leicht ist, ist das Laden sehr schwer und langwierig. Bei einer JavaScript-Weiterleitung durch das A/B-Testing-Tool müssen die erste Seite und alle Ressourcen (Bilder, Skripts, usw.) ein erstes Mal geladen sein, bevor die zweite Seite anfängt zu laden. So wird zwar der Flicker-Effekt vermieden, die Ladedauer der Seite aber erheblich verlängert. Tests mit Weiterleitung sollten nur benutzt werden, wenn es wirklich keine andere Möglichkeit gibt, weil sie einen sehr negativen Einfluss auf die Performance haben. Bei einer totalen Neugestaltung Ihrer Webseite, mit der neuen Version auf einem anderen Server ist das z.B. so gut wie unumgänglich. In allen anderen Fällen sollten Sie JavaScript-Weiterleitungen vermeiden.

Wenn Sie bereits Kameleoons neue 100% flickerfreie Technologie benutzen, brauchen Sie die nächsten Empfehlungen nicht mehr, wie:

• Sich so weit wie möglich auf Style Sheets verlassen. Mit Kameleoon macht das keinen Unterschied mehr, Sie können die Einstellungen wählen, die Sie wollen, Kameleoon kümmert sich automatisch um die Performance.
• Nicht jQuery benutzen. Kameleoon benutzt keine externe Bibliothek, was das Gewicht des Skripts weiter vermindert. Die neuen Webseiten (und viele von Ihnen sind dabei, umzusteigen) basieren eher auf neuen Frameworks wie Angular oder React, was jQuery immer mehr zu einem unnötigen Gewicht macht. Außerdem ist Vorsicht geboten: auch wenn Ihre Webseite schon jQuery beinhaltet, reicht es nicht, es aus der A/B-Testing Lösung zu nehmen. Wenn das jQuery-Skript spät lädt, besteht erneut (und völlig unnötig) Flicker-Gefahr.
• Den Code Ihrer Änderungen optimieren, um keine unnötigen JavaScript-Anweisungen einzufügen. Kameleoons Graphic Editor generiert keine JavaScript-Anweisungen, sondern basiert auf einem Motor, der die Änderungen des Nutzers umsetzt. Das Problem ist damit aus dem Weg geräumt.

Es gibt eine weitere Regel, die wir in der Vergangenheit empfohlen haben, heute aber unnötig ist: „setInterval“nutzen, um Änderungen der von Ihnen getargeten Elemente so schnell wie möglich vorzunehmen. Genau hier liegt das Problem, das wir mit der neuen Technologie gelöst haben.

Man muss mit unterschiedlichen Größenordnungen spielen und den idealen Parameter finden, der den Flicker-Effekt ausschaltet, ohne die CPU-Dauer des A/B-Testing-Tools zu beeinträchtigen.

Genau diese Herausforderung sind wir angegangen: unsere Lösung vermeidet den „Pi mal Daumen“-Effekt, der mit setInterval einhergeht und spart so den Entwicklern von A/B-Tests wertvolle Zeit. Die Polling-Lösung setInterval, wird unnötig: Die Änderungen werden durchgeführt, sobald das Element in den DOM der Seite injiziert wird.

Kurzum

Wie unser Partner Altima sehr richtig feststellt, müssen die Best-Practice Regeln befolgt werden. Ohne sie ist auch die innovativste Technologie machtlos. Unser Ziel ist es, die Innovation kontinuierlich voranzutreiben, um unseren Kunden die Arbeit zu erleichtern.

Dank unserer neuen Technologie konnten sie von einem (wenn auch kleinen) Flicker-Risiko zu einer 100% flickerfreien Lösung übergehen. Und das ist ein echter Fortschritt.