Ein browserbasierter Python-Playground, der eine 5,5 MB große Runtime ausliefert, begann bei Nutzern mit langsamen Verbindungen unbemerkt auszufallen. Die Ursache war eine falsch verwendete Network Information API und ein Dashboard zur Fehlergruppierung, das das Problem falsch beschriftete. Der Bug blieb wochenlang verborgen, verschwendete Entwicklerzeit und verhinderte, dass ein Teil der Nutzer Code ausführen konnte.

Wie das Problem auftrat

Der Error-Tracker des Playgrounds zeigte eine einzige, auffällige Meldung an: „undefined is not an object.“ Der Titel deutete auf einen einfachen JavaScript-Tippfehler hin, woraufhin das Team einem nicht existierenden Code-Pfad nachjagte. Als sie die Rohdaten der Metadaten untersuchten, stellten sie fest, dass 89 % dieser Vorfälle tatsächlich Netzwerk-Timeouts waren. Das Dashboard hatte den ersten eingetroffenen Fehler genommen und diesen zur Benennung des gesamten Batches verwendet, wodurch der eigentliche Fehlertyp maskiert wurde.

Lektion 1 – Dashboard-Titel können täuschen

Ein Dashboard, das Vorfälle aggregiert, hilft nur dann, wenn seine Aggregationslogik die tatsächliche Ursache jedes Ereignisses widerspiegelt. In diesem Fall zeichnete die Gruppierung nach Standort statt nach Fehlerursache ein falsches Bild eines clientseitigen Bugs. Das Learning: Beheben Sie ein Problem niemals ausschließlich auf Basis einer Dashboard-Überschrift. Ziehen Sie eine Stichprobe der zugrunde liegenden Ereignisse und prüfen Sie, was wirklich passiert, bevor Sie Ressourcen zuweisen.

Lektion 2 – Platzhalterwerte sind keine Messungen

Um das Laden der massiven Runtime für Nutzer mit langsamen Verbindungen zu vermeiden, fragte der Code die Network Information API ab und las die Eigenschaft downlink aus, die Megabit pro Sekunde angibt. Beim ersten Besuch gibt Chrome oft einen Platzhalter anstelle einer tatsächlichen Messung zurück. Die Logik behandelte diesen Platzhalter als schnelle Verbindung und übersprang die Optimierung, wodurch genau die Nutzer blockiert wurden, denen eigentlich geholfen werden sollte.

Behandeln Sie jeden Standard- oder Sentinel-Wert als „keine Daten“. Ein Platzhalter sollte eine Fallback-Strategie auslösen und darf nicht als tatsächlicher Geschwindigkeitswert interpretiert werden.

Lektion 3 – Netzwerkbedingungen ändern sich, daher ist eine Momentaufnahme unzuverlässig

Nach dem Problem mit downlink wechselte das Team zur Überprüfung von effectiveType, was Verbindungen in Kategorien wie „4g“, „3g“ usw. einteilt. Ein kurzer Labortest war erfolgreich, aber derselbe Test schlug nur Augenblicke später fehl. Mobile Verbindungen schwanken; ein Nutzer kann in einer Sekunde über eine schnelle 4G-Verbindung online sein und im nächsten Moment auf ein langsameres 3G zurückfallen. Die Verbindung nur beim Laden der Seite zu prüfen, ist ein Glücksspiel.

Der richtige Ansatz besteht darin, das change-Event des Network Information Objekts zu abonnieren und auf jede Änderung der Bandbreite zu reagieren, anstatt eine einmalige Entscheidung zu treffen.

Was das Team geändert hat

  • Zweistufiger Download – Die Runtime beginnt nun mit einer winzigen Bootstrap-Datei. Wenn die Verbindung als langsam identifiziert wird, lädt der Bootstrap den Rest der Runtime in kleinen Häppchen herunter, was die Wahrscheinlichkeit eines vollständigen Abbruchs verringert.
  • Live-Monitoring – Anstatt eines einzelnen downlink-Werts hört der Code nun auf change-Events und passt die Download-Strategie während des Vorgangs an.
  • Stabile Quellenauswahl – Zuvor wechselte das System mitten im Download das CDN, sobald ein schnellerer Endpunkt verfügbar war. Bei einer langsamen Verbindung führte dies dazu, dass der Download wieder bei Null begann, was das Problem verschlimmerte. Die neue Logik fixiert die Quelle für die gesamte Dauer eines Downloads.
  • Verzögerte Cache-Schreibvorgänge – Schwere Cache-Operationen, die früher ausgeführt wurden, bevor die App nutzbar war, werden nun auf die Zeit nach dem Start der Runtime verschoben, um Bandbreite für den kritischen Download freizugeben.

Die übergeordneten Auswirkungen

Für Entwickler, die webbasierte Tools bauen, ist die Variabilität des Netzwerks ein zentrales Anliegen. Ein unbemerkter Fehler bei einer langsamen Verbindung frustriert Nutzer und verfälscht die Telemetrie, was Teams auf falsche Debugging-Pfade führt. In diesem Fall führte die Fehlinterpretation von Daten zu wochenlangen, ergebnislosen Untersuchungen.

Worauf man künftig achten sollte

Fazit: Wenn Daten zu „sauber“ aussehen, handelt es sich wahrscheinlich um einen Platzhalter; wenn eine Dashboard-Überschrift auf einen einzelnen Bug hinweist, graben Sie tiefer; und wenn Sie eine Entscheidung auf Basis einer einmaligen Netzwerkmessung treffen, setzen Sie auf ein bewegliches Ziel. Die Berücksichtigung dieser Realitäten verwandelt unbemerkte Fehler in vorhersehbare, behebbare Ereignisse.