Błędy w konsoli: które psują sprzedaż, a które można zignorować

Klasyfikacja błędów JavaScript według wpływu na użytkownika, pułapki source map i jak oddzielić własny kod od cudzych widżetów.

JavaScript · Opublikowano: 22 lipca 2026 · 3 min czytania · Марк Лебедев

Otwórzcie DevTools na dowolnym sklepie — czerwonych linii będzie od trzech do trzydziestu. Część jest niegroźna, część codziennie po cichu zjada konwersję. Różnica nie tkwi w treści błędu, lecz w tym, co dzieje się z użytkownikiem po nim.

Trzy poziomy wpływu

Blokujące. Wyjątek poleciał przed podpięciem handlerów — przycisk „Kup" po prostu nie reaguje. Klasyk: Cannot read properties of undefined w inicjalizacji modułu. Użytkownik widzi stronę, która wygląda sprawnie i nie robi nic.

Częściowe. Psuje się jeden widżet: mapa, slider, kalkulator dostawy. Reszta strony żyje, ale scenariusz się nie domyka.

Szumowe. Błąd analityki, żądanie zablokowane przez rozszerzenie, ResizeObserver loop limit exceeded. Nie wpływają na zachowanie, ale maskują prawdziwe problemy w strumieniu logów.

Co niemal zawsze warto naprawić

• Uncaught (in promise) TypeError — nieobsłużony reject, za którym zwykle stoi niedokończone żądanie sieciowe.
• Failed to fetch na własnej domenie — to CORS albo padnięty backend, nie „glitch przeglądarki".
• Hydration failed w React/Vue — markup serwera i klienta się rozjechał; zaraz potem znikają handlery.
• Błędy wewnątrz handlerów submit — prosta droga do niewysłanego formularza.

Pułapka source map

Bez map źródeł stos wygląda jak main.4f2a.js:1:88213 i na tym śledztwo się kończy. Poprawny układ: generować sourcemapy przy każdym wydaniu, wysyłać do systemu monitoringu i nie publikować ich obok bundla — inaczej źródła stają się publiczne. W większości bundlerów to flaga hidden-source-map.

Oddzielajcie cudzy kod

Skrypty czatu, reklam i testów A/B generują połowę błędów i prawie żadnego, który możecie naprawić. Ustawcie filtr po domenie źródła:

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

Dzięki temu własne błędy nie toną w cudzych. Osobno ustalcie budżet: jeśli zewnętrzny widżet dokłada więcej niż N błędów dziennie, wylatuje albo zostaje wymieniony.

Sprawdzać przed produkcją

Błędy czasu wykonania nie łapią się linterem ani typami: powstają na prawdziwych danych. Tani sposób, by wyprzedzić problem, to przepuszczać kluczowe strony przez headless browser przy każdym wydaniu i przerywać build, gdy pojawią się nowe błędy konsoli. Pięć minut w CI kontra tydzień niezauważonej awarii zamówień.

I trzymajcie historię: ten sam błąd wracający po każdym deployu to nie „pływający bug", tylko niezamknięty wyścig przy ładowaniu.