For convenience, there is also a fiddle of the benchmarks here: https://jsfiddle.net/kspearrin/1Lzvpzkz/

Note: It is expected that there will be slowness compared to a raw JS implementation, due to JS getting heavily JIT'ed in ways that make it insecure for crypto - which is part of the core reason for WebCrypto's existence, which is the inability to make reasoned guarantees about the timing safety of the crypto.

There is also expected overheads for smaller payloads due to (safely) expanding the key schedule, which may be amortized over larger blobs - this is both a cost of correctness and the cost of the optimizations involved.

Finally, there is a cost involved with the invocation overhead, due to WebCrypto requiring a thread transition as currently implemented, due to the need to not block the event loop from processing other events, whereas JS can be paused/interrupted arbitrarily during execution by the engine. This could be improved if we synchronously completed things on Workers, but as discussed in the W3C Web Crypto WG (before it shut down), that itself is problematic from a compat perspective.

All of these things contribute to 'correct' vs 'fast', which is a common trade-off in security sensitive, timing-dependent operations.

(This isn't to excuse looking for optimizations where they exist, but also to make sure to set realistic fundamental expectations)

Thanks for the benchmark!

I believe the biggest difference in performance seen here on small operations is due to the asynchronous API + Chrome's multi-threaded implementation.

These computationally small tasks end up copying the data buffers and posting to another thread, waiting to be scheduled there, and then again waiting to be scheduled when posted back to JS thread.

There are some other internal costs like needing to make an extra copy of data buffers in case algorithm normalization mutates them , and delivery of the result through a Promise can also hit scheduling bottlenecks.

Issue 435790 has a suggested optimization that should speed up this particular benchmark (I agree these results are disappointing) so I will tentatively dupe against that on the assumption that the performance problems you saw here were the scheduling ones.

For high performance Web Crypto I think we want a synchronous mode for Web Workers, as that solves both the scheduling overheads, as well as the lack of parallelism controls (raised in other bugs as a limiting factor for throughput).