Archiv der Kategorie: Tag Manager

WTF ist ein SPOF?

Eine Webseite ist ein wunderbarer Spielplatz für Marketing & Business (und manchmal auch IT), um verschiedene Tools auszuprobieren, die es ermöglichen sollen den (potentiellen) Kunden und sein Verhalten zu verstehen. Von den klassischen Analyse-Tools wie Google Analytics bis hin zu Heatmap Tracking Tools, wie crazyegg, ist die Bandbreite weit gefächert. Letztere zeichnen auf wie es sich mit der Aufmerksamkeit des Users auf einer Seite verhält. Oft wird die einfache Einbindung in die Seite über so genannte Tag Manager ermöglicht, so dass der Aufwand für die IT sehr gering ist. So weit so gut.

Leider kommt es häufig vor, dass sich diese Ressourcen als Single Point of Failure (SPOF) in einer Seite entpuppen. Ein SPOF ist ein Element in einem Konstrukt, dass, wenn es „bricht“, es zu einem Scheitern des gesamten Konstrukt kommt. Im Kontext von Webseiten bedeutet es, dass die Webseite verlangsamt geladen wird. Dieses verlangsamte Laden kann nur ein paar Millisekunden bedeuten, was für den Besucher vielleicht kaum merkbar ist. Es kann aber auch bedeuten, dass die Webseite sehr lange braucht, um komplett geladen zu werden. So lange dass ein Besucher das Laden abbricht und woanders hin surft, da er denkt, dass die Seite nicht mehr reagiert. Im schlimmsten Fall sieht der Nutzer nur ein leeres Browserfenster – auch White Screen of Death (WSoD) genannt.

Dabei ist nicht die Ressource selber das Problem oder die Verwendung eines Tag-Managers. Es kommt darauf an, wie die Ressource in die Seite eingebunden wird. Oft sind solche SPOFs JavaScripte, die das Laden weiterer Elemente blockieren, so lange sie selber nicht komplett geladen, geparst und prozessiert sind. Dies ist übrigens das Standardverhalten von Webbrowsern, wenn ihm nix anderes mitgeteilt wurde. Wird ein Script ganz zu Beginn in einer Seite referenziert (z.B. HEAD), kann es zu einem WSoD kommen.

Dieses Verhalten ist natürlich unschön und mindert das User-Engagement deutlich, da steigender Ladezeit der Besucher der Seite ungeduldiger wird. Daher ist es wichtig SPOFs zu identifizieren und nach Möglichkeit zu entfernen. Insbesondere bei 3rd Party Integrationen fällt das Erkennen manchmal schwer. Zur Analyse eignet sich das Tool SPOF-O-Matic sehr gut, dass als Chrome Erweiterung erhältlich ist. Es wurde von den Betreibern von webpagetest.org entwickelt und enthält eine Möglichkeit ein Video mit dem Worst Case zu generieren – also dann wenn die Ressource nicht geladen werden kann.

Dabei gibt es zwei Kategorien von Ressourcen: Die Einen, die einen wesentlichen Bestandteil der Aufgabe der Seite liefern – visuell oder funktional. Und die, die sekundäre Aufgaben erfüllen, wie Analytic Tools. Bei der ersten Kategorie muss bewertet werden, ob sie wirklich das Risiko eines SPOFs wert ist. So können nachgeladene Schriften (z.B. von Google) ebenfalls blockieren. Natürlich hat eine Schrift keinen funktionalen Wert, aber der visuelle Character der Seite geht ohne diese Schrift eventuell verloren. Die zweite Art sollte ganz klar entschärft und asynchron nachgeladen werden, denn die Enduser Experience steht im Vordergrund. In diesem Zusammenhang sollte man sich die Frage stellen, ob die eingebundene Ressource es überhaupt wert ist, dass sie in der Webseite enthalten ist und Ladezeit kostet.

Ist man zu dem Schluss gekommen, dass man die Ressource benötigt, muss dafür gesorgt werden, dass sie asynchron und nicht blockend geladen wird. Dazu bieten sich die Möglichkeiten DEFER und ASYNC als Attribut von <script> an. Beide verhindern das Blockieren der Weiterverarbeitung der Webseite im Browser. In der Regel ist DEFER die richtige Wahl, da die Ressource dann parallel zum restlichen Inhalt geladen wird, aber erst geparst und prozessiert wird, nach dem das HTML Dokument selbst komplett geladen und geparst ist (DOMContentLoaded). Es gibt nur sehr wenige Situationen in denen ASYNC über DEFER gewählt werden sollte, da bei ASYNC die Ressource zwar auch parallel geladen wird, aber sobald sie vollständig geladen ist, sofort geparst und prozessiert wird. D.h. wenn sie schnell geladen ist, kann sie sich wieder blockierend auswirken. Daher ist eine genaue Kenntnisse der Webseite bzw -applikation von Nöten. Insbesondere bei Applikationen, die sich aus vielen Quellen zusammensetzen. Darüberhinaus gibt es noch weitere Möglichkeiten mit JavaScript Ressourcen asynchron nachzuladen, auf diese gehe ich in einem späteren Blogpost ein. Das Beispiel „Web Font Loader“ sei hier aber erwähnt.

Um es noch einmal zu verdeutlichen: Die in diesem Beispiel angeführten Analytic Tools sind nicht die einzigen Ressourcen, die blockieren können. Sie fallen allerdings häufig auf, da sie vermehrt zum Growth Hacking eingesetzt werden. Social Media Plugins sind ebenfalls ein oft gesehener Kandidat und diese haben meist nichts mit der Aufgabe der Seite zu tun. Aber auch extern geladene Web-Schriften können das Laden blockieren, wie wir gesehen haben.

 

Anmerkung: Den Begriff White Screen of Death (WSoD) verwende ich nicht ganz korrekt, da er eher beschreibt, dass die Anwendung oder das Device überhaupt nicht mehr reagiert. Das ist aber wie beschrieben weder für Browser noch Webseite der Fall. Es kommt nur zu einer Verzögerung. Diese kann allerdings sehr lang sein und ich kenne niemanden, der bereit ist 20 Sekunden und mehr auf eine Antwort zu warten. Und das ist auch gut so.