New Raygun JS provider v2.27.0 to support performance timing

| 3 min. (627 words)

Deprecation of Performance.timing in browsers: New Raygun JS provider v2.27.0 for compatibility

The popular chromium based browser ecosystem has recently changed how performance metrics can be collected in relation to performance.timing.

Before we get into the details, the TLDR is: if you use the Raygun CDN for raygun4js, you’re up to date. If you self-host raygun4js and use Raygun Real User Monitoring, you’ll want to upgrade to version 2.27.0.

What was deprecated?


The old method extracts a PerformanceTiming object stored in the reference window.performance.timing. In new browser versions, the reference is not properly maintained anymore, so some of its fields may return null: Depending on how your application is trying to dereference fields out of it, e.g., via (window.performance.timing.responseEnd - window.performance.timing.startTime) for measuring the load time of a page, you might get null or nan (not-a-number) values. As such, if your website’s javascript code assumes that this is the only way to extract navigation metrics, you will start seeing bad numbers increasingly coming in as more and more end-users update their browser to the latest versions.

What has it been replaced with?

The new way of acquiring an object that can return performance data is via a call to window.performance.getEntries() and relevant methods, such as getEntriesByName() and getEntriesByType(). These will return an array of PerformanceEntry objects that are available when these methods are called. Depending on the nature of the measurement one needs to perform, you then need to select the appropriate instance from the returned array to work with. For example, if you wanted to measure the load time of the page, you’d select the PerformanceEntry instance of type PerformanceNavigationTiming. Then, assuming you store this in a reference called timing, you’d get the load time via timing.duration.

How is this affecting Raygun’s customers?

Raygun’s RUM product relied on the old way of taking performance measurements. As such, when customers’ end-users started updating their browsers, any sessions captured started introducing corrupt timing data to the events. From a software architecture perspective, end-users are accessing the Raygun JS file via three ways:

  • Directly from Raygun, via a script HTML entry that fetches the file from our CDN using the URL //
  • Wrapped in a bundle via our Raygun4js npm package.
  • Wrapped in a bundle via our Raygun4js nuget package.

What has Raygun done to fix this?

We have published a new minor-version release for our Raygun4js provider, version 2.27.0. This version is backwards compatible with both types of navigation performance measurement. As such, it will simultaneously work for both end-users who have updated to the latest browsers’ versions and those who have not done so yet. Further, we released accompanying versions 2.27.0 for the bundled solutions for nuget and npm.

What do Raygun customers need to do now?

This issue affects only RUM customers. If you do not use RUM, you are not affected. However, if you do use your own custom performance solution, we urge you to implement a backwards-compatible solution as the one discussed above.

As a RUM customer, if you are not bundling our js file via npm and/or nuget, you do not need to do anything! Your end users will get the latest version 2.27.0 from us–we have also ensured that our CDN caches have been invalidated to avoid older versions being delivered.

However, if you are using one of the bundled options via npm or nuget, we urge you to update to the latest raygun4js 2.27.0 version immediately! You will need to execute the update via the appropriate process for each package management system and then make a new release of your application.

What happens next?

Following the instructions above should resolve any issues. Nevertheless, we’re available to help out and answer questions. Please contact for assistance from our expert team.