Die Auswirkungen von Polling auf Single-Page-Applications

Die Auswirkungen von Polling auf Single-Page-Applications

Eines der größten Herausforderungen in der Umsetzung von A/B Tests und Personalisierungs-Kampagnen ist das Event-Handling. Vor allem Single-Page-Applications und Webseiten die Inhalte dynamisch nachladen, sind davon betroffen. Eine Methode die häufig eingesetzt wird, ist das Polling.

In diesem Beitrag möchte ich erläutern was Polling genau ist, welches Risiko es mit sich bringt und warum man darauf am besten verzichten sollte.

Was ist ein Event?

Bevor ich auf das Polling eingehe, sollte zunächst geklärt werden was in Entwickler-Sprache unter einem Event verstanden wird.

Ein Event oder Ereignis wird in der Entwicklung zur Steuerung des Programmflusses genutzt. Das bedeutet, dass zu einem bestimmten Ereignis (Event), Programm-Code ausgeführt wird.

Eines der bekanntesten Events ist das Klick-Event. Auf ein Event folgt meist eine Aktion. Diese Aktion wird in einer Funktion beschrieben, die wiederum durch das Event getriggert wird. Die Funktion nennt man auch Callback-Funktion. In diesem Beispiel enthält die Callback-Funktion eine Zeile Code, die „Fire click event“ in die Konsole schreiben soll, sobald der Nutzer irgendwo in den „body“ geklickt hat.

document.querySelector("body").addEventListener("klick", function() {
    console.log("Fire click event");
});

Events haben verschiedene Gesichter und leider lässt sich nicht jedes Event so einfach abfangen wie ein Klick. Das gilt vor allem Events die nicht durch den Nutzer ausgelöst werden, sondern z.B. den Server. 

In der Regel sieht man also nur das Ergebnis eines Events. Ein gutes Beispiel dafür sind Single-Page-Applications. Auf eine Anfrage des Clients, wird von einem Webservice des Servers mit einem dynamischen Inhalt geantwortet, der davon abhängt, welche Eingaben der Nutzer gemacht hat.

Dynamischer Content

Im obigen Beispiel antwortet der Server auf den Add-To-Cart mit dynamischen Content, der in den Mini-Basket eingefügt wird. Man könnte jetzt zwar auf die Idee kommen, den Klick auf den „In den Warenkorb“-Button zu tracken, aber das wäre nicht korrekt. Wenn das Produkt nämlich ausverkauft wäre, könnte der Server mit einem Fehler antworten. Dann wäre der Klick gezählt worden, aber der Add-To-Cart war überhaupt nicht erfolgreich. 

Es muss also einen besseren Weg geben. Einer davon ist das sogenannte Polling.

Polling

Als „Polling“ beschreibt man in JavaScript das Verwenden der Methode setInterval, zur ständigen Abfrage einer Bedingung. Dabei wird in einem Abstand von x Millisekunden Code ausgeführt. Das Interval wird beendet, sobald die Bedingung erfüllt wurde. 

Anbei eine Polling-Funktion für die eigene Toolbox. Der Methode werden vier Parameter übergeben:

  • condition: die zu prüfende Bedinungung
  • callback: die Funktion die aufgerufen werden soll, wenn die Bedingung erfüllt wird
  • interval (optional): Abstände in Millisekunden in der das Interval ausgeführt wird
  • timeout (optional): Timeout in Millisekunden, der das Interval nach der vorgegeben Zeit beendet, sofern die Bedingung zuvor nicht erfüllt wurde 

Das Add-To-Cart Beispiel von oben, könnte mit dieser Funktion so gelöst werden, dass das Einfügen des „Zum Warenkorb“-Buttons als Bedingung genutzt wird. Wenn der Button also erscheint (der Server antwortet mit dynamischen Content, der den Button enthält) soll die Callback-Funktion ausgeführt werden. In dieser CB-Funktion wird eine Message in die Konsole geloggt mit dem Inhalt „Add-To-Cart erfolgreich“.

console.log("Add-To-Cart erfolgreich");
Polling im Einsatz

Übrigens: Wenn es darum geht lediglich das Einfügen eines Elements im DOM zu prüfen, gibt es eine deutlich und bessere und ressourcenschonendere Methode die ich bereits hier verbloggt habe.

Das Risiko von Polling

Polling ist unter Entwicklern eher verpönt. Denn Polling ist sehr ressourcenhungrig. Das Interval erzeugt einen Vorgang bei dem der Code sich in einer Schleife wiederholt. Sollte die Bedingung nie erfüllt werden, endet auch das ständige Abfragen nie. Das kann, vor allem in Kombination mit weiteren Polling-Funktionen, zu signifikanten Performance-Problmen führen. Im aller schlimmsten Fall ist die Seite nicht mehr benutzbar oder der Browser schmiert sogar komplett ab.

Trotzdem gibt es Situationen in denen man nicht um das Polling herum kommt. Muss man sich dann um seine Kampagnen sorgen machen? Die Antwort lautet ganz klar Jaein

Solange Polling dosiert eingesetzt wird und die technische Qualitätssicherung nichts dagegen hat, gibt es keine Bedenken. Allerdings hat nicht jeder eine technische Ressource in der Qualitätssicherung. Darum sollte in der Spezifikation darauf hingewiesen werden, auf Polling zu verzichten sofern möglich. Sollte man dennoch nicht sicher sein, dann hilft es während der QS die Aktivitätsanzeige des Rechners zu beobachten. Diese würde im Falle, dass etwas mit dem Code nicht stimmen sollte, eine signifikante Auslastung (mehr als 70 oder 80 %) der CPU anzeigen.

Hohe CPU-Last bei Polling

Man sollte nicht vergessen, dass es deutliche Leistungsunterschiede zwischen den Endgeräten gibt. Während Desktop-Rechner nicht so schnell an ihre Grenzen kommen, gehen unter Umständen alte Smartphones oder Tablets direkt in die Knie.

Single-Page-Applications

Bei einer „normalen“ Webanwendung, kann man in der Regel davon ausgehen, das Inhalte nach dem Laden der Seite zur Verfügung stehen. Bei SPAs ist das anders. Der Content wird ständig dynamisch nachgeladen. 

Selbst wenn die Webseite keine SPA per Definition ist, nutzen viele Unternehmen die Technik für bestimmte Bereiche auf Ihrer Seite. Erfahrungsgemäß wird im E-Commerce der Checkout-Prozess zur SPA. In der Versicherungs-Branche, die Antragsstrecke.  

Das erschwert die Arbeit von Entwicklern von A/B-Tests und Personalisierungs-Kampagnen erheblich. Denn JavaScript Code wird bei jedem Page-Load in der Regel synchron (nacheinander) ausgeführt. Damit kann der Code jedes mal aufs Neue den Ist-Zustand der Seite abfragen. Lädt die Seite aber nicht neu, wie etwa bei SPAs, dann müssen andere Techniken zum Einsatz kommen – u.a. sind das Polling und Mutation Observer.

Langfristiger Lösungsansatz

Um den Aufwand und vor allem die Fehleranfälligkeit von Kampagnen für Single-Page-Webanwednungen zu reduzieren wäre z.B. eine Callback-Funktion seitens der SPA, eine Lösung. Diese Funktion würde über die window-Property des Browsers global zu Verfügung gestellt werden. Sie ließe sich anschließend über das A/B-Testing Tool nutzen und könnte auf die Events zugreifen, die ursprünglich nur dem Frontend der Webseite vorbehalten waren.

tl;dr

Polling kommt vor allem bei SPAs und Seiten mit dynamischen Inhalten zum Einsatz. Das größte Risiko dabei sind Performance-Probleme. Diese lassen sich durch eine intensive QA eindämmen. Für einen langfristigen Erfolg bei der Umsetzung von Kampagnen, sollte auf Polling nach Möglichkeit verzichtet werden und andere Wege für das Handling der Events gefunden werden.

Titelbild: Photo by Irvan Smith on Unsplash

Schreibe einen Kommentar

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

Nächster Beitrag:

Mutation Observer: Auf Änderungen im DOM reagieren

Mutation Observer: Auf Änderungen im DOM reagieren