von Max Vith

5 nützliche Tipps, um bei der Umsetzung von Experimenten keine Conversions zu verlieren

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 bekommen deine 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. Ein A/B-Tests kann heute von der einfachen Anpassung von Bild und Text bis hin zu einem neuen Feature oder Module reichen.

  1. Die Vorgehensweise eines Front-End-Engineers mit einem Schwerpunkt in der Entwicklung von A/B-Tests ist eher systematisch, diszipliniert, quantifiziert und basiert dabei auf wissenschaftlichen Ansätzen.
  2. Die Tätigkeit eines Web-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 Conversion Rate 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 und sicherstellen, dass die Umsetzung (deine Technik) als Störquelle eleminiert werden kann, damit das Konzept und die Hypothese ohne Einfluss von Technik performen können, oder eben nicht.

 

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. Das hat früher schon banaler geklungen als es war 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. Wenn ein A/B-Test erfolgreich ist, wird er in das System des Kunden übernommen. Durch das Einhalten der Prinzipien können Teile eines A/B-Tests (Quellcode) in das Produktivsystem (Live-System) übernommen werden.

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. Der Verzicht auf JavaScript-Bibliotheken steigert zudem 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 einer 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 wir

Fazit: Dateigrößen, Clean-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 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!

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!

Max Vith

Max Vith

Max Vith ist als Head of Front-End-Engineering bei konversionsKRAFT für die Entwicklung und Durchführung von A/B-Tests sowie der technischen Beratung verantwortlich. Als Dozent und Coach bildet er zudem Informatiker im Bereich Front-End-Engineering aus und weiter. Seine Erfahrungen im Feld der Conversion-Optimierung konzentriert sich dabei seit 8 Jahren auf Performance, Agilität und Effektivität. Er sorgt für optimierte Experimente und berät zu User Experience, Single-Page-Applications und weiterer Web-Technologien, sowohl im Front- als auch Back-End-Bereich.
Frage zum Artikel? Frag den Autor!

1 Reaktion auf „5 nützliche Tipps, um bei der Umsetzung von Experimenten keine Conversions zu verlieren

  1. Vielen Dank für den Artikel. Ich lese sehr gerne solche informativen Artikel für den Start meines eigenen Onlinebusiness 

Schreibe einen Kommentar

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