Immer wieder kam und kommt es zu Situationen, in denen man auf seinen Webseiten Funktionen umsetzen oder Partner einbinden möchte, die durch das Einbinden einer JS-Datei total schnell und easy auf eine Seite gelangen könnten.
Das kann für kleine Websites auch ein gängiges Modell sein. Wenn man aber große Websites betreut, die wirklich Milliarden an Seitenaufrufen im Monat generieren oder einen für eine Firma betriebskritischen Charakter vorweisen und dort bereits komplexeste Funktionen ablaufen, dann kann man auf die Behauptung, man müsse nur ein JS einbinden und sich um nichts weiter kümmern, nur mit einem freundlichen aber bestimmten „You wish!“ antworten.
Immer, wenn jemand so etwas äußert, ist markant Vorsicht geboten. Mindestens mal muss das ausgiebig und optimaler Weise unter Realbedingungen getestet werden. Und am besten schaut man sich im Detail ganz genau an, was das Stück Software macht, das man sich da auf die Seite holt. Denn jedes eingebundene JavaScript erhält die volle Macht über die Seite.
Und dabei kann so vieles passieren:
- Die Performance der Seite geht in die Knie
- Die Datenmenge wird schlagartig größer
- Andere Funktionen laufen nicht mehr
- Unerklärliche Dinge passieren
- Nutzer werden mal eben zu einer Dritt-Seite „entführt“, um denen da ein Cookie zu verpassen und wieder zurückzuleiten
- Datenschutzverstöße
- Sicherheitslücken
Du brauchst dich um nichts kümmern
Als ich bei einem meiner Kunden vor einigen Jahren neu anfing und das Initalbriefing zu den zahlreichen kleinen und großen Anforderungen erhielt, die ich betreuen durfte, wurde mir eines der Projekte folgendermaßen vorgestellt:
„Das ist ABCD, hier wissen schon alle Bescheid, du musst dich um nichts kümmern. Das geht nächste Woche live. Da kommt nur ein Stück JavaScript auf unsere Seite.“
Natürlich beglückt man neue Kunden nicht mit einem „You wish!“ sondern ich antwortete mit „alles klar!“.
Als dann kaum zwei Tage später der erste Entwickler auf mich zu kam und fragte, was genau hier denn gemacht werden sollte, zeichnete sich irgendwie bereits ab, dass das wohl doch nicht so reibungslos über die Bühne gehen würde, wie man sich das eingangs so dachte.
Genau genommen, war nämlich gar nix klar, was die Implementierung und Auswirkung auf die Seite angeht. Und es begann feinstes Projekt-Gedöns:
- Die Software wurde auf einer Messe in den USA präsentiert mit „ihr müsst nur ein Stück JavaScript auf die Seite einbinden, ganz einfach, dann könnt ihr damit Geld verdienen“.
- Die Software wurde von einer Führungsperson eingekauft, die üblicher Weise nicht fokussiert ist auf den Einkauf oder die Implementierung von Software
- Die Software wurde an der IT-Abteilung vorbei eingekauft und es wurde auch nicht geprüft, ob das so einfach implementierbar ist. Klar, denn es musste ja nur ein Stück JavaScript auf die Seite.
- Es wurde bereits via Pressemitteilung angemerkt, dass wir nun diesen Dienstleister einbinden und das in den folgenden Wochen live gehen würde.
- Erste Tests nach Implementierung warfen Fragen auf:
- Wie genau soll das denn alles im Adminbereich des Anbieter konfiguriert werden? Es hat sich nämlich bis zu diesem Zeitpunkt keiner Gedanken über die Fachlichkeit gemacht.
- Ja genau, es gibt einen Adminbereich, wo alles auch noch konfiguriert werden muss. Sowas kann ja keiner ahnen.
- Auf welchen Seitentypen oder in welchen Bereichen soll die Software denn laufen?
- Wie soll das gute Ding denn aussehen? UX, Design?
- Wie läuft das denn mit denn Apps?
- Ist das kompatibel mit allen Geräten und Betriebssystemversionen, die wir grundsätzlich unterstützen wollen?
- Man war not amused, dass ich so viele Fragen stellte und aufzeigen musste, dass man den avisierten Zeitrahmen mit großer Wahrscheinlichkeit mal gepflegt vergessen kann.
Nach 6 Monaten umfangreichen Analysierens, Konzipierens, Implementierens, Testens und sehr sehr viel Kommunikation zwischen verschiedensten Parteien ging es es dann endlich live. Also nur knapp etwas mehr als die vorgegebene eine Woche.
Das ist natürlich in der Projektwelt nichts Ungewöhnliches. Böse Zungen behaupten ja immer, dass man bei einer Projektlaufzeit-Schätzung diese immer verdoppeln und die nächst höhere Zeiteinheit nehmen soll. Wenn man also sagt, das Ganze dauert 4 Tage, dann sind es eigentlich 8 Wochen.
Als wir damit nun aber tatsächlich live waren, passierten interessante Dinge, die trotz ausgiebiger Tests zuvor nicht aufgefallen waren und die sich auch keiner auf Anhieb erklären konnte. Geschweige denn, dass am Anfang bereits deutlich war, dass der neue Dienstleister dieses Problem verursachen würde, da Dienstleister und der Bereich des auftretenden Problems „eigentlich“ gar nichts direkt miteinander zu tun hatten.
Es passierte Folgendes:
Es gibt Werbebanner, die aus mehreren einzelnen Werbepositionen bestehen und zusammen eine große Werbefläche ergeben. In diesem Fall ein sogenanntes Fireplace Ad. Dieses Fireplace Ad zeigte in dem linken Teil Werbung von irgendwas, was der AdServer gerade so auslieferte, und im mittleren und rechten Teil die eigentlich gewünschte Werbung eines Autoherstellers. D.h. die große Werbefläche, die aus 3 Teilen ein Gesamtbild zeigen soll, und auch nur in vollständiger Form sinnvoll ist und gezählt werden darf, war kaputt.
Es ist einem Kunden auch schwer zu erklären, warum sein Fahrzeughersteller-Werbemittel zu einen Drittel aus Tütensuppen-Werbung bestehen sollte.
Sowas hat natürlich erst einmal Implikationen auf die Vermarktung bzw. die Kundenbeziehung. Reges Treiben und Verlust der kommunikativen Etikette sind dann häufig zu verzeichnen. Denn der Kunde bezahlt (viel) Geld, sein Werbemittel wird aber nicht korrekt ausgeliefert und erzielt damit nicht den gewünschten Effekt. Also muss man das Problem lösen und Kompensation zahlen und/oder entsprechende Werbeauslieferungen nachliefern.
Was wir dann herausbekommen haben:
Das lustige neue JavaScript entführte den Nutzer für den unmerkbaren Bruchteil einer Sekunde zu einer Seite des Anbieters, um dort ein Cookie zu verarbeiten und schickte ihn dann wieder zurück. Das kann gutgehen, muss es aber nicht.
Das hatte zufolge, dass der AdServer, der auch via JavaScript auf der Seite eingebunden ist, beim Laden eben dieser Seite schon mal losgelaufen ist und den ersten Teil des Fireplace-ADs offiziell auslieferte. Und während er gerade im Begriff war, das auch mit den anderen Teilen des Werbemittels zu tun, kam das neue JavaScript des anderen Anbieters mit einer Blutgrätsche von rechts, zog den Nutzer auf die besagte andere Seite. D.h. alle anderen in dem Moment laufenden JavaScript-Aktionen auf unserer Seite wurden natürlich unterbrochen, weil der Nutzer physikalisch nicht mehr da war sondern halt woanders in diesem Internetz.
Als dann der Nutzer wieder zurückgeleitet wurde, lief der AdServer wieder los und hätte nun alle drei Teile der Werbung laden können.
Nur leider gab es ein Frequency-Capping auf dem Werbemittel, welches dafür sorgte, dass eine Werbung nur ein einziges Mal pro Nutzer ausgeliefert werden sollte. D.h. der erste Teil der Werbung war technisch gesehen schon ausgeliefert, auch wenn der Nutzer das nie gesehen hat, weil er ja im Millisekundenbereich entführt wurde. Aber der AdServer ist ja ein Computer und bekommt Dinge schneller mit als ein Mensch. Daher hat er sich die bereits erfolgte Auslieferung gemerkt und darf entsprechend hier die Werbung nicht noch mal ausliefern.
Doof gelaufen. Ungünstige Konstellation verschiedenster Parameter. Und der Zeitraum, bis man so etwas identifiziert und auf einem Live-System gefixt hat, kann mal ein paar Stunden bis Tage dauern.
Zurück zum eigentlichen Thema
Mit jedem JavaScript, was man sich auf eine Seite holt, kann es zu Herausforderungen kommen. Insbesondere weiß man nie, wann ein Stück JavaScript anfängt oder wann ein anderes genau endet oder wo sie sich da torpedieren.
Man sollte also immer wissen, was die eingebundenen JS-Bibliotheken auf der eigenen Seite so veranstalten und auch wann sie da ihre Party feiern. Wenn man das vorher nicht weiß und ggfls. auch nicht die passenden Testcases bereit hält, dann kann mal Blödsinn passieren. Im Zweifel auch sehr teurer Blödsinn.
Würde man jetzt anfangen wollen, zu koordinieren, wann welches JS losläuft und bspw. immer warten würde, bis das nächste starten darf, ja, das könnte man machen. Aber man möchte seinen Nutzern die fertige gerenderte Website auch so schnell wie möglich anzeigen und ihn nicht durch immens lange Ladezeiten verprellen. Von der Komplexität bei der Implementierung wollen wir an dieser Stelle noch gar nicht sprechen.
Da bleiben nur folgende Dinge, die man mitnehmen sollte:
- Augen auf, beim JavaScript-Kauf!
- Traue niemandem, der behauptet, man müsse nur ein JavaScript auf die Seite einbinden und sich ansonsten um nichts kümmern. Insbesondere keinem gewieften Vertriebsmenschen. Egal wie nett sie/er einem den Kaffee (mit oder ohne Schuss) einschenkt.
- Lasst niemanden Software für ein Unternehmen einkaufen, ohne das mit Kollegen*innen zu besprechen, die das ggfls. sinnvoll bewerten könnten.
Und wenn wir ehrlich sind, gilt das nicht nur für Websites und JavaScript sondern für jegliche Bibliotheken, die man sich in seine (auch klassischen) Softwareprojekte einverleibt.
Nicht nur während Corona-Zeiten gültig:
Stay save, get tested!