Consider the following test URL:
https://linxin2020.github.io/hls_live/js_performance.html
Disclaimer: I do not own that page, but it serves as a good test case.
The page in question is making some calls to the Web Audio API and measures the response time. In my tests, it returns in 10-30ms on Firefox and Chrome (both on Windows) whilst Brave (again on Windows, desktop) it returns in about 20-30s.
On my laptop, it spins up fans and will soon hang the browser for the above duration. On my high-end desktop, it also freezes the thread, for pretty much the same amount of time.
So the device seems to not matter that much, Brave is about a 1000-2000x slower compared to other browsers in running this script.
I don’t know anything about the underlying cause for this, but given that it’s so Brave-specific, I can speculate that this may be extra code running in Brave to counter fingerprinting? Because indeed, Web Audio scripts similar to this are used in fingerprinting libraries.
I’m all for combating fingerprinting, but that should not be an excuse to completely freeze the user’s browser. Fingerprinting libs are sometimes used in ecommerce sites to combat fraud, especially when payments are involved. I don’t care to debate whether they should do this, I’m just stating it as an observation. Consequently, this means that when a consumer visits such ecommerce website in Brave, it fully locks up, whilst it doesn’t in other browsers. A consumer isn’t likely to understand why this happens, hence I hope this can be looked at.