It&#x27;s complicated. For starters, if you&#x27;re looking for a _secure_ PRNG most practitioners would strongly advise _against_ the system you described[1]. There&#x27;s a difference between a cryptographically secure algorithm and a secure system. For the overall system to be secure you need to make sure the seed data is secured, which you&#x27;re bound to fail at unless you really know what you&#x27;re doing.<p>Providing a &quot;cryptographically secure but not really secure&quot; alternative implemented in user space alongside a &quot;really secure&quot; alternative that&#x27;s been thoroughly vetted would likely just add to the confusion. If you _really_ need secure numbers you should be using the really secure one. The really secure one is almost definitely going to require a syscall worth of overhead, at least, so it&#x27;s _definitely_ going to be slower than a PRNG like xorshift128+ which literally takes a single digit number of CPU cycles.<p>Now to answer your question, if you&#x27;re just talking about a CSPRNG algorithm they&#x27;re probably fast enough for almost every use case. I think there&#x27;s still an argument for some things like array shuffling, but those implementations could go out of their way to use the non-CS algorithm as an optimization. Unfortunately in Javascript land there&#x27;s aren&#x27;t many batteries included, so if you switched Math.random() to use a CSPRNG most people would end up using it for trivial stuff like shuffling arrays. If you&#x27;re talking about a secure system... it&#x27;s probably still fast enough for most things, but it&#x27;s less obvious.<p>[1]<a href="http:&#x2F;&#x2F;sockpuppet.org&#x2F;blog&#x2F;2014&#x2F;02&#x2F;25&#x2F;safely-generate-random-numbers&#x2F;" rel="nofollow">http:&#x2F;&#x2F;sockpuppet.org&#x2F;blog&#x2F;2014&#x2F;02&#x2F;25&#x2F;safely-generate-random...</a>