Console errors: which ones cost sales and which are noise

JavaScript errors sorted by user impact, the source-map trap, and how to separate your own code from third-party widgets.

JavaScript · Published: 22 July 2026 · 3 min read · Марк Лебедев

Open DevTools on any commercial site and you will find between three and thirty red lines. Some are harmless; some quietly eat conversion every day. The difference is not in the error text but in what happens to the user afterwards.

Three levels of impact

Blocking. The exception is thrown before handlers are attached — the "Buy" button simply does not respond. The classic is Cannot read properties of undefined during module initialisation. The user sees a page that looks functional and does nothing.

Partial. One widget breaks: a map, a slider, a shipping calculator. The rest of the page is alive, but the flow never completes.

Noise. An analytics error, a request blocked by an extension, ResizeObserver loop limit exceeded. No effect on behaviour, but they mask the real problems in the log stream.

What almost always deserves a fix

• Uncaught (in promise) TypeError — an unhandled reject, usually with an incomplete network request behind it.
• Failed to fetch on your own domain — that is CORS or a backend that fell over, not "a browser glitch".
• Hydration failed in React/Vue — server and client markup diverged; missing handlers follow.
• Errors inside submit handlers — a direct route to an unsent form.

The source-map trap

Without source maps the stack reads main.4f2a.js:1:88213, and the investigation ends there. The correct setup: generate source maps per release, upload them to your monitoring system, and do not ship them next to the bundle — otherwise your source becomes public. In most bundlers that is the hidden-source-map option.

Separate somebody else's code

Chat, advertising and A/B testing scripts produce half the errors and almost none you can fix. Filter by origin:

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

That keeps your own errors from drowning in other people's. Set a budget separately: if a third-party widget contributes more than N errors a day, it gets removed or replaced.

Check before production

Runtime errors are caught by neither linter nor type system: they arise on real data. A cheap way to get ahead of them is to run the key pages through a headless browser on every release and fail the build when new console errors appear. Five minutes of CI against a week of a silently broken checkout.

And keep history: the same error returning after every deploy is not a "flaky bug", it is an unresolved race during loading.