von Manuel Brückmann

5 Tipps beim A/B-Testing, die jeder Front-End-Entwickler kennen sollte

Heute wissen wir längst, dass die Lade- und Reaktionszeiten eines Onlineshops wesentlichen Einfluss auf die Conversion Rate haben.

Aber in Bezug auf Testing und Optimierung ist die Baustelle eine andere.
Wurden früher in einfachsten A/B-Tests Bilder oder Texte getauscht, werden heute konfigurierbare Templates, neue Features oder Module verprobt.

Was bedeutet dieser Umstand eigentlich für deine IT, und wie findet ihr den Spagat zwischen technischem Aufwand, Schnelligkeit der Seite und sauberem Code?

In diesem Beitrag gebe ich dir 5 Tipps an die Hand, mit denen du eine hohe Testing-Performance sicherstellst, ohne dass sich die Seite im Ladeverhalten oder in der Ausspielung massiv verschlechtert. Denn im Idealfall bekommt dein Besucher von all den Tests im Hintergrund gar nichts mit.

Developer, Engineer, Fullstack oder doch Front-End-Entwickler: Was denn nun?

Grundsätzlich gilt: Performance is King – das ist eigentlich nichts Neues.

Sollen bei einem bestehenden E-Commerce System Änderungen getestet werden ohne, dass schwerwiegende Eingriffe in die Templates vollzogen werden müssen, so kommt man nur mit JavaScript-Manipulation, HTML-Injection und CSS-Anpassungen weiter.

Hier ist der Punkt, an dem der „ordentliche“ Entwickler aufpassen muss.

In den letzten Jahren hat sich das Feld Conversion Engineering deutlich vergrößert. So sind heute Grundkenntnisse in HTML, CSS und JavaScript und einem Framework wie jQuery nicht mehr ausreichend, um komplexe A/B-Tests zu entwickeln.

So können A/B-Tests von einer einfachen Anpassung von Bild und Text bis hin zu einem neuen Feature oder Module reichen, die über einen Cloud-Service ausgeliefert sowie Daten gespeichert und ausgewertet werden.

  1. Das Aufgabenfeld eines Conversions Engineers umfasst das eines Front-End-Engineers mit einem Schwerpunkt: die Entwicklung von Experimenten.
  2. Die Vorgehensweise eines Front-End-Engineers ist eher systematisch, diszipliniert, quantifiziert und basiert dabei auf wissenschaftlichen Ansätzen.
  3. Die Tätigkeit eines Developers dagegen basiert nicht auf Metriken oder wissenschaftlichen Grundsätzen – weshalb der Erfolg der Entwicklung eher Zufall ist.

Mit anderen Worten, die Tätigkeit eines Front-End-Engineer basiert auf für die Conversionrate relevanten Faktoren – wie beispielsweise wissenschaftliche Hypothesen – während sich der Web-Developer ausschließlich mit der Umsetzung auseinandersetzt, ohne dabei den entsprechenden Rahmen und Hintergrund zu kennen.

Mit den folgenden 5 Tipps lassen sich die gröbsten Fallen vermeiden.

Tipp 1: Sauberer Code & Guidelines

Ein guter Entwickler will immer sauberen, validen und wartbaren Code erzeugen.

Dennoch gilt, je weniger Zeichen der manipulierende Code verbraucht, desto besser. Hat früher schon schwierig geklungen und ist heute noch schwieriger umzusetzen.

Das Ladeverhalten der Seite darf nicht massiv verschlechtert werden. Warum verwende ich den Begriff “massiv” an dieser Stelle? Weil es ganz ohne Verzögerung bei -basierten Systemen nicht geht.

Je länger das Laden des Tests und die Ausführung der Manipulationen dauert, desto mehr wird die User Experience negativ beeinflusst. Beispielsweise wird die Seite subjektiv als langsam empfunden, wenn sich Inhalte umbauen und die fertige Seite erst sehr spät visuell zur Verfügung steht.

Das Einhalten der Clean Code Prinzipien gibt sehr gute Richtlinien.

So reduzieren Prinzipien wie POLS, KISS, DRY, YAGNI oder SOLID nicht nur den Aufwand für die Wartung des Quellcodes, sondern optimieren die Performance der Testausspielung automatisch. Sollte ein A/B-Test erfolgreich abgeschlossen werden, wird eine Implementierung in das Produktivsystem vereinfacht.

Damit auch externe Mitarbeiter oder Agenturen die Prinzipien der eigenen IT-Abteilung einhalten können, sollten vorhandene Code Guidelines geteilt werden.

Abgerundet wird die Entwicklung mit einem automatisierten Build-System wie Grunt oder Gulp, wodurch JavaScript und CSS optimiert und minimiert wird.

Bonus-Tipp: Die Definition von Code Guidelines und die Verwendung von Code-Analyse-Tools ist ein überschaubarer Aufwand, reduziert nachträglich aber selbigen direkt, sobald erfolgreiche Tests in das System übernommen oder als 100% Veröffentlichung ausgespielt werden.

Tipp 2: Native JavaScript Performance schlägt jQuery

Früher hatte fast jede E-Commerce Plattform eine JavaScript-Bibliothek wie jQuery oder Dojo synchron im Head-Tag implementiert, damit die Grundfunktionalitäten wie Navigationselemente sofort vorhanden waren. Doch diese Zeiten sind vorbei.

Durch die Verwendung von Frameworks und Libraries wie Angular oder React ist das zusätzliche Implementieren genannter JavaScript-Bibliotheken nicht mehr notwendig. Als Überbleibsel werden diese meistens am Ende der Seite nachgeladen, damit noch vorhandene Plugins funktionieren. Diese Altlasten werden jedoch nach und nach aus den Webseiten entfernt.

Für die Entwicklung von A/B-Tests war jQuery ein wahrer Segen. DOM Manipulationen konnten mit wenigen Funktionsaufrufen durchgeführt, Ajax Requests abgefangen oder verwendete Plugins manipuliert werden.

Viele A/B-Test-Entwickler tun sich bei einem Umstieg auf natives JavaScript schwer. Dies führt in der Regel zu Problemen bei der Performance der Testausspielung, da die notwendige Abhängigkeit mitunter verzögert geladen oder im schlimmsten Fall über das Testingtool selbst nachgeladen wird.

Doch ist ein Wechsel auf natives JavaScript wirklich so schwierig?

Diese Frage lässt sich ganz klar mit “nein” beantworten.

A/B-Tests müssen und sollten heute nicht mehr mit JavaScript-Bibliotheken erstellt werden. Zudem steigert es die Performance der Testausspielung enorm. Neben deutlich weniger zu ladenden Datenmengen (keine JavaScript-Bibliothek), ist die Ausführungszeit von nativem JavaScript gegenüber jQuery um ein Vielfaches schneller.

Bonus-Tipp: Für alle, die vor einem Umstieg auf natives JavaScript stehen, erleichtern Seiten wie youmightnotneedjquery einen Umstieg ungemein.

Tipp 3: Mehr CSS, weniger JavaScript

Durch Polling, also eine permanenten Prüfung auf neu hinzugefügte Elemente im DOM, können Manipulationen sehr performant mit JavaScript vorgenommen werden.

Ein Unterschied zwischen CSS und JavaScript ist größtenteils nicht mehr zu erkennen, dennoch gilt für uns weiterhin die Regel „Verwende CSS, wenn du es kannst“.

Und hier findet für den „ordentlichen“ Entwickler der größte Bruch statt.

Sollen beispielsweise Elemente im Quellcode verschoben werden, so wäre der sauberste Ansatz eine Verschiebung innerhalb des DOMs mit anschließendem Deployment und die Ausspielung des A/B Tests über einen Split-URL-Test oder backend-seitig sicherzustellen.

Ein erfahrener Front-End-Entwickler würde das Element per JavaScript im DOM verschieben oder eine Kopie erzeugen. Der Code wäre damit auch nach der Manipulation vom Markup her sauber.

CSS bietet jedoch einige Vorteile.

Der größte Vorteil: CSS steht sofort zur Verfügung, wenn es dem Dokument hinzugefügt wurde.

Es muss auf kein Element gepollt oder sogar auf JavaScript Events gewartet werden. Die Manipulationen können direkt per CSS durchgeführt werden – soweit möglich versteht sich. Es mag unsauber sein und einem ordentlichen Entwickler falsch vorkommen, aber:

  • das absolute (Um)Positionieren von Elementen,
  • dafür Platz schaffen durch paddings und margins,
  • direktes Ausblenden von unnötigen Elementen oder
  • das Ergänzen von Textbausteinen oder Grafiken (z.B. CSS Pseudo-Klassen),
  • die Elemente per Grafiken hinzuzufügen oder zu animieren,

ist im Ergebnis – und das ist worauf es letztendlich beim Testing ankommt – deutlich effizienter.

Bonus-Tipp: CSS Dateien können sehr einfach innerhalb einer Cloud oder dem eigenen Server gehostet, per Testingtool vorgeladen und bei der Testausspielung eingebunden werden. Zusammen mit einem Caching erreicht man so eine bestmögliche Performance der Testausspielung.

Tipp 4: Reduktion von Assets

Jede Grafik bzw. jedes Asset, welche oder welches im Rahmen einer Testvariante nachgeladen werden muss, verzögert zusätzlich das Laden der Seite. Das hat ebenfalls sowohl einen physikalischen Einfluss auf die Ladezeit als auch auf die Wahrnehmung – also das gefühlte Fertigladen der Seite.

Hier hat sich speziell durch das Einführen des HTTP/2 Protokolls einiges geändert. Die meisten Server und Drittanbieter unterstützen das neue Protokoll, wodurch sich der zusätzliche Aufwand für die Erstellung von Grafik-Sprites nicht mehr rechnet.

Eine größere Rolle spielen heute die Datenmengen von JavaScript und CSS. Diese haben sich durch komplexere Testumsetzung sowie der Verwendung von Bibliotheken und Frameworks deutlich erhöht.

Die meisten Testingtools bieten die Möglichkeit von globalen JavaScript und CSS pro Experiment an, wodurch Redundanzen vermieden und die Codemenge deutlich reduziert werden kann.

Basieren die Varianten 1 bis 3 beispielsweise auf einem einheitlichen HTML-Template mit gleichen Funktionen, kann im Zusammenspiel mit einem automatisierten Build-System wie Grunt oder Gulp das Template einmalig entwickelt werden. Nur die unterschiedlichen Texte müssen im jeweiligen Code der Varianten hinterlegt werden. Dies reduziert nicht nur die Codemenge deutlich, sondern vereinfacht das Bugfixing sowie die Wartung des A/B-Tests deutlich.

Bonus-Tipp: Sollte es noch keinen automatischen Build-Prozess geben, können Tools wie CodeKit für Mac oder Prepos für Windows diesen Workflow sehr einfach automatisieren.

Tipp 5: User Experience Ansätze nutzen

Ein weiterer Einflussfaktor auf die Wahrnehmung hat das Ergänzen von Elementen. Nicht immer können bestehende Inhalte angepasst werden, auch neue Elemente müssen gegebenenfalls erzeugt werden.

Dies geht ausnahmslos per JavaScript, was das bereits angesprochene Störgefühl erzeugen kann. Hier bieten sich gängige Methoden aus der User Experience an. Es können zum Beispiel Elemente „weich“ per Fading eingeblendet werden, anstatt sie „hart“ hinzuzufügen.

Oft ergibt auch die Kombination aus CSS und JavaScript Sinn, sodass beispielsweise der Raum für die Ergänzung bereits per CSS geschaffen wurde, und JavaScript letztendlich nur noch für das Einfügen zuständig ist.

Dadurch wird zum einen die Testsituation verschleiert, zum anderen das gefühlte „Umbauen“ der Seite gemindert.

Bonus-Tipp: Es gibt keine Möglichkeit mehr, ein Flackern zu verhindern? Hier kann mit einem Platzhalter und einer Ladeanimationen gearbeitet werden, wodurch die Verzögerung als solche nicht negativ wahrgenommen wird.

Fazit: Dateigrößen, sauberer Code und Cross-Browser-Kompatibilität sicherstellen

Nicht nur die Dateigröße der Testinhalte, sondern auch der Umfang der Maßnahmen, z.B. die JavaScript Rendertime des Browsers, haben einen Einfluss auf die Test-Performance.

Das Ziel ist es, dem Testteilnehmer nicht das Gefühl zu vermitteln, Versuchskaninchen im Labor zu sein, sondern die Website im Originalzustand zu besuchen. Nur wenn die Testsituation neutral ist, kann auch von validen Zahlen und einem fairen Test ausgegangen werden.

Bei den beschriebenen 5 Tipps gilt es natürlich eins nicht zu vergessen: die Cross-Browser-Kompatibilität.

Noch heute sind ältere Browser im Einsatz, speziell der Internet Explorer 11. Weiterhin gilt es also einen Blick in die Webanalyse Zahlen zu werfen, um abzuwägen, wie weit man bei der Cross-Browser-Kompatibilität zurückgehen muss.

Ist der Prozentsatz der Nutzer, die den Browser im Einsatz hat, niedrig, ist es oft wirtschaftlicher, den alten Browser vom Test auszuschließen, anstatt eine umfangreiche Anpassung vorzunehmen.

Die Erfahrung zeigt, dass mit Ausnahme des B2B-Marktes die Nutzung von Browsern mit entsprechenden Fähigkeiten deutlich überwiegt im Vergleich zur Nutzung veralteter Browser.

Welche weiteren Tricks nutzt du, um eine gute Testing-Performance, ein gutes Ladeverhalten sowie eine gute Ausspielung sicherzustellen? Wir freuen uns auf weitere Tipps!

Developer-Power gesucht

Du kanntest bereits alle Tipps? Sehr gut!
Clean Code Prinzipien sind eines deiner 10 Gebote, und du hast Lust auf spannende neue Aufgaben? In unserem Karrierebereich findest du aktuelle Stellen in den Feldern Entwicklung, IT & Qualitätsmanagement. Wir freuen uns über deine Kontaktaufnahme!

 

Manuel Brückmann

Manuel Brückmann

Manuel Brückmann, Jahrgang 1982, ist als Principal Technology Consulting bei konversionsKRAFT – Deutschlands führende Agentur für Conversion Optimierung – für den Bereich Technologie Beratung verantwortlich.

Sein Werdegang begann 2007 im Bereich Design & Usability. Mit dem Abschluss als Dipl. Ing. (FH) Medieninformatik sammelte er als Consultant und Projektmanager in den darauf folgenden 2 Jahren Erfahrungen, bis er 2009 in den Bereich Interaction Design & Interface Development wechselte. Zwei Jahre später sammelte er in der Rolle des Senior User Experience Engineer Erfahrungen im UX-Bereich. In den folgenden Jahren übernahm er seit Anfang 2012 die Verantwortung für den Bereich Conversion Engineering bei konversionsKRAFT und führte eine interdisziplinäre Business Unit. Seit Anfang 2016 gehört er zur Geschäftsleitung und übernahm dort die Führung der Technologie im Unternehmen. Seit 2019 konzentriert er sich als Principal Technology Consulting auf die technischen Beratungsthemen im Unternehmen.

Neben umfangreichen Kenntnissen aus dem Bereich Technologie und Engineering (Web Oberflächentechnologien, Rich-Media, User Experience, Mobile / Responsive) weist er 12 Jahre Erfahrungen in den Bereichen Conversion Optimierung, E-Commerce, Lead-Gen, Usability, Projekt-, Account -und Team-Management vor.

Frage zum Artikel? Frag den Autor!

7 Reaktionen auf „5 Tipps beim A/B-Testing, die jeder Front-End-Entwickler kennen sollte

  1. Danke für den Artikel.

    Wieder „Futter“ zum verarbeiten.

    Gruß,
    Michael

  2. Mit Blick auf Besucherstatistiken frage ich mich, ob die Verwendung von JavaScript tatsächlich sein muß? Ein nicht unbeträchtlicher Anteil von Besuchern unserer Seite hat JS deaktiviert. Daher kann ich nur empfehlen, die VErwendung von JS weitestgehend zu vermeiden.

  3. von Manuel Brückmann

    Hallo Herr Fuchs,
    danke für Ihr Feedback. Grundsätzlich stimme ich Ihnen zu. Sofern Ihre Kunden tatsächlich in einer signifikaten Größe JavaScript deaktiviert haben, sollte möglichst auf dessen Verwendung verzichtet werden – zumindest was die Kernfunktionen angeht.
    Allerdings ist dies – so unserer Erfahrung nach – eher die Ausnahme. Kunden haben heut zu Tage (Dank moderner Browser) in der Regel JavaScript aktiviert. Dies zeigt auch die aktuelle Webhits-Statistik (http://www.webhits.de/deutsch/index.shtml?webstats.html) bei der rund 94% aller Nutzer JavaScript aktiviert haben.
    Der Artikel bezog sich weniger auf Shops allgemein, sondern eher auf Testing innerhalb von eCommerce Systemen. Mit wenigen Ausnahmen ist dort Testing ausschließlich durch JavaScript möglich. Hat ein Nutzer JavaScript deaktiviert, nimmt er nicht am Test teil. Auch die Performance-Tipps sind eher in diesem Kontext zu sehen. Nur im Testingumfeld sollte z.B. durch CSS die Verwendung von DOM-Manipulation durch JavaScript umgangen werden (aufgrund des beschriebenen Szenarios). Überall dort, wo ein sauberes Markup notwendig ist (z.B. für SEO) sollte dies beibehalten werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.