Konsolenfehler: welche den Umsatz kosten und welche Rauschen sind

JavaScript-Fehler nach Nutzerwirkung sortiert, die Source-Map-Falle und wie man eigenen Code von fremden Widgets trennt.

JavaScript · Veröffentlicht: 22. Juli 2026 · 3 Min. Lesezeit · Марк Лебедев

Öffnen Sie die DevTools auf einer beliebigen Shop-Seite — es werden drei bis dreißig rote Zeilen sein. Ein Teil ist harmlos, ein Teil frisst täglich still die Conversion. Der Unterschied liegt nicht im Fehlertext, sondern darin, was danach mit dem Nutzer passiert.

Drei Wirkungsstufen

Blockierend. Die Exception fliegt, bevor Handler registriert sind — der „Kaufen"-Button reagiert schlicht nicht. Klassiker: Cannot read properties of undefined in der Modul-Initialisierung. Der Nutzer sieht eine funktionstüchtig aussehende Seite, die nichts tut.

Teilweise. Ein Widget bricht weg: Karte, Slider, Versandrechner. Der Rest der Seite lebt, aber der Ablauf endet nicht.

Rauschen. Analytics-Fehler, eine von einer Extension blockierte Anfrage, ResizeObserver loop limit exceeded. Ohne Wirkung auf das Verhalten, aber sie überdecken echte Probleme im Logstrom.

Was fast immer repariert gehört

• Uncaught (in promise) TypeError — ein unbehandelter Reject, dahinter steckt meist eine abgebrochene Netzwerkanfrage.
• Failed to fetch auf der eigenen Domain — das ist CORS oder ein ausgefallenes Backend, kein „Browser-Hänger".
• Hydration failed in React/Vue — Server- und Client-Markup laufen auseinander; danach fehlen Handler.
• Fehler innerhalb von submit-Handlern — der direkte Weg zum nicht abgeschickten Formular.

Die Source-Map-Falle

Ohne Source Maps sieht der Stack aus wie main.4f2a.js:1:88213, und damit endet die Untersuchung. Richtig ist: pro Release Source Maps erzeugen, ins Monitoring hochladen und nicht neben dem Bundle ausliefern — sonst liegt der Quellcode öffentlich. In den meisten Bundlern ist das die Option hidden-source-map.

Fremden Code abtrennen

Skripte für Chat, Werbung und A/B-Tests liefern die Hälfte der Fehler und fast keinen, den Sie beheben können. Filtern Sie nach Herkunftsdomain:

window.addEventListener("error", (e) => { const own = e.filename?.startsWith(location.origin); report(e, { severity: own ? "error" : "third-party" }); });

So gehen eigene Fehler nicht in fremden unter. Setzen Sie zusätzlich ein Budget: Bringt ein Drittanbieter-Widget mehr als N Fehler pro Tag, fliegt es raus oder wird ersetzt.

Vor der Produktion prüfen

Laufzeitfehler fängt weder Linter noch Typsystem: Sie entstehen an echten Daten. Ein billiger Weg, ihnen zuvorzukommen, ist, die wichtigsten Seiten bei jedem Release im Headless-Browser durchzuspielen und den Build abzubrechen, wenn neue Konsolenfehler auftauchen. Fünf Minuten CI gegen eine Woche unbemerkt kaputter Kasse.

Und führen Sie Historie: derselbe Fehler nach jedem Deploy ist kein „sporadischer Bug", sondern eine ungelöste Race Condition beim Laden.