Thanks for the question.
I'll answer it as "detecting BPM from an audio file." The thing that matters most here is a premise that isn't stated yet: whether the audio holds a roughly constant tempo.
With something like EDM, the pulse is explicit and this is fairly tractable. With jazz, classical, or live drumming, the spacing between beats keeps moving, and collapsing that into one correct BPM is hard even with AI. Waveform analysis and beat detection still work as techniques, but if the peaks aren't evenly spaced, there isn't a single clear tempo to extract in the first place.
If you can assume a mostly steady tempo, then yes, the browser is enough.
If an existing library covers your case, using one is the fastest path. If you want to do it yourself, here's the simplest version of the idea. This is a rough sketch for material with clear attacks, not a general-purpose algorithm.
Say the sample rate is 44.1 kHz and you decide the slowest tempo you'll accept is 40 BPM.
Mix the stereo down to mono.
Treat 44100 × (60/40) = 66150 samples as the longest a single beat can be, and use that as your window.
Find the peaks (attacks) and measure the distance between them in samples, then convert to seconds.
For example, 35461 samples gives 35461 / 44100 ≈ 0.804 seconds, and 60 / 0.804 ≈ 74.6, so roughly 75 BPM.
On real music, whether those peaks are actually beats is a separate problem. Half-tempo and double-tempo confusion is very common. If this is going into a product, it's more realistic to return several candidates with a confidence value, or to let the user override with a tap tempo.
As for where to run it: for static analysis of a whole file, a Web Worker is the right place. For real-time, use an AudioWorklet. Running heavy analysis on the main thread is worth avoiding. WASM is an option too, but once you're copying the entire buffer across the boundary, it can end up slower than it looks.
One last thing. The question isn't really "does the tempo move a lot" so much as "can you reliably see the beat as a peak." For material that breathes, a tempo curve or an editable beat grid tends to be more useful than a single BPM number.
I work on Imaju, which deals with timing analysis in the browser, so if it's useful as a reference, the difference between steady-tempo detection and genuinely loose human timing is something you can see there.
https://imaju.creathree.com/
