We use Amplitude, who use their own forked version of this library in their browser SDK.

A big chunk of Amplitude's initialization time is spent in ua-parser's getResult(), see profile below:

This profile is for Chrome running on macOS on a MacBook Pro.

Given that our detection logic is basically, scan through the userAgent string with a list of regexes until one matches then stop. The worst case is O(n) where n is the number of regexes (per feature we're detecting, browser/os/device/etc ...)

We can't optimize the worst case scenario without radically changing this library's design (e.g: to a one-pass parse of the userAgent), but we can significantly improve the performance of the common case for popular configurations.

If we focus on the list of os regexes, macOS & iOS are near the end, whereas less popular OSes (e.g: blackberry, nintendo/playstation, ...), which means the rgx() call with have to test all those lesser popular platforms before getting to iOS/macOS.

The same is true for the browser regexes, Chrome is near the end of that list despite being the most popular browser on the market.

Additionally there doesn't seem to be an overlap between regexes that would require running some of them before others for correctness. So it seems like a no-brainer to sort regexes by their popularity (Chrome, Edge, Firefox, Safari, ...), (Windows, Android, iOS, Mac, ...)