6 Tips for Reducing JavaScript Error Noise

DZone 's Guide to

6 Tips for Reducing JavaScript Error Noise

Learn how to reduce JavaScript error noise and find JavaScript zen with these six great tips from a web developer. Read on to get started!

· Web Dev Zone ·
Free Resource

If you're trying to build and iterate on your app using JavaScript error tracking, you might be suffering from a common affliction: noisy, low-value notifications that make it hard to identify high-priority issues.

Browser JavaScript is perhaps the single most complex environment from which to capture errors because it's not just one environment! There are multiple major browsers, JavaScript engines, operating systems, and browser extension ecosystems, all of which come together to make capturing good errors pretty infuriating (but not less crucial to the performance of your app).

Error tracking platforms like Sentry do a decent job out-of-the-box cutting through all the noise. But, for the best results, there are a few simple but game-changing steps you can take to increase signal and make iteration more straightforward — even enjoyable.

Whitelist Your URLs

Sentry's browser JavaScript SDK picks up every uncaught error triggered from your web app by default. That includes code running on your page that isn't necessarily authored or controlled by you. These include errors triggered by browser extensions, malware, or third-party applications like chat widgets, analytics, and ad code.

To ignore such problematic errors, you can configure the SDK to whitelist errors originating solely from your own code:

Raven.config('your-dsn', {
    whitelistUrls: [
        'www.example.com/static/js', // your code
        'ajax.googleapis.com'        // code served from Google CDN

This example configuration ensures that only errors that originate from scripts served from www.example.com/static/js and ajax.googleapis.com are reported to the Sentry server. This small configuration change is the easiest, most impactful change you can make to reduce errors.

Use Inbound Data Filters

Inbound data filters are a Sentry feature designed to discard known low-value errors from your projects. They are easily toggled inside your Sentry project settings, and any errors they discard as a result do not count towards your account quota.

There are three filters that are particularly valuable for JavaScript developers:

  • Legacy browsers – old browsers like IE9 produce low-fidelity error reports that aren’t always actionable.
  • Third-party extensions – automatically drop errors from known browser extensions, malware, and ad scripts.
  • Web crawlers – drop errors triggered from known web crawlers like Google Bot.

Inbound filters are not as powerful as configuring the Sentry JavaScript SDK to whitelist error URLs, but they're nice because they can be enabled with a single click from inside your project settings.

Use the Latest Version of the JavaScript SDK

Sentry's browser JavaScript SDK is under active development, and changes are frequently made to both improve the _quality_ of error reports and reduce the quantity of low-value errors.

For example, version 3.26.2 suppresses back-to-back duplicate errors by default. This is a life-saver if you are suffering from errors that trigger from asynchronous loops (e.g., from setTimeout or XMLHttpRequest callbacks). In long-lived applications, errors like these can result in thousands of events for a single user!

To get the best experience, keep your copy of the SDK up to date. Sentry will tell you when there's a new version available, but it's also worth checking the changelog periodically to see what's new.

Image title

Use Source Maps

Source maps don’t just make debugging your production stack traces easier, they make it easier for Sentry to group errors into individual issues. This means that events bucket into a smaller, more manageable set of issues, which means less noise in your issue stream and fewer 2:00 am emails about broken code.

Making source maps a part of your build and deploy process isn't as easy as toggling a button, but Sentry’s in-depth source map documentation has everything you need to get started. Besides helping to reduce noise, source maps may be the single most profound improvement you can make to your monitoring and debugging workflow.

Ignore Troublesome Errors

Some errors you're just never going to fix. When they pop up, you realistically have two options:

1. Declare bankruptcy because they’ll ruin your app and you have no way to resolve them.

2. Ignore them entirely because they ultimately have no bearing on the user’s experience.

You can ignore the error either via the Sentry UI or by configuring the JavaScript SDK to prevent them client-side, using the ignoreErrors option. Doing so from the SDK is ideal because errors discarded at the client-level do not reach Sentry's servers and do not count against your account quota.

Here's what it looks like:

Raven.config('your-dsn', {
    ignoreErrors: [
        'Can\'t execute code from freed script',
        /SecurityError\: DOM Exception 18$/

Be careful though! Once you make this change, you'll never see these errors again. And error strings that were previously just nuisances could become bigger problems down the line, but you'll never be informed of them. Yikes! Choose your ignoreErrors array wisely.

Note that browsers can produce different error messages for the same fundamental error. For a single ReferenceError, you may need to input multiple strings/regexes to cover all possible browsers.

Upload Your Source Files (and Source Maps)

When Sentry encounters an error triggered from a JavaScript file, it attempts to download that source file from your app servers in order to correlate line and column information with actual source content. This source content is the basis of Sentry's error grouping algorithm.

If your source files are only accessible over the web, many, many bad things that can happen. For example, you might have a build process that removes old JavaScript files from servers as you deploy new ones. If your users trigger errors from older cached scripts, they will no longer be available when Sentry goes to download them. Not having access to that content can mess up the grouping algorithm, which means separate issues will be created for errors that would normally be bucketed under an existing issue.

To avoid these and other interruption scenarios (e.g., network availability), we strongly recommend you upload your production JavaScript files and source maps as release artifacts. This means that Sentry will always have direct access to these files, ensuring maximum grouping effectiveness.

Uploading source files is done using the Sentry API. It’s pretty simple:

$ curl https://sentry.io/api/0/projects/:organization_slug/:project_slug/releases/:release/files/ \
  -X POST \
  -H 'Authorization: Bearer YOUR_TOKEN_HERE' \
  -F file=@app.js.map \
  -F name="http://example.com/app.js.map"

Learn more about artifacts and releases in the documentation.

We're Here to Help

As always, you can try Sentry for your JavaScript app (it’s 100% open source, too).

That’s it! Happy error monitoring.

error tracking ,javascript ,sdk ,web application development ,web dev

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}