New Raygun JS provider v2.27.0 to support performance timingPosted Aug 11, 2023 | 3 min. (627 words)
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
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
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
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
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 //cdn.raygun.io/raygun4js/raygun.min.js
- 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 firstname.lastname@example.org for assistance from our expert team.