It's like when people compare Java to C and say that it runs as fast or faster in some limited benchmark. Performance isn't some homogenous thing where a single test can characterize performance completely. JavaScript, due to its untyped nature with an inherently weak memory management system makes it difficult to have scalable, predictable performance. Under limited conditions, it can hang with the best of languages, thanks to the advanced JIT compilers that are integrated into browsers, but the language itself is very poorly designed for performance, so even the best JIT tech can't make up for that.

You could write code that looks wonderful, but actually has untyped variables whose types cannot be predicted accurately, causing traps that exit the wonderful world of JITted performance and fallback to either a low speed JIT or to being purely interpreted, which causes performance to drop by a spectacular amount. A similar set of code could rely too heavily on creating large amounts of intermediate garbage, which can cause the garbage collector to swoop in and slow your code to a crawl. Simple things like dynamically expanding an array inside a loop, doing some kind of comprehension on the array, and then an outer loop starting all over, which would destroy the intermediate array -- an array that generated enormous amounts of garbage while being constructed, only to be destroyed and generate more garbage.

These are just a couple of the really obvious performance hiccups, but then you have the issue of concurrency. Web Workers are a relatively new technology, and they seek to solve the issue, but they're cumbersome to use and have quite a lot of restrictions.

Just because JavaScript can perform well in certain limited situations against C# -- just like Java against C -- doesn't mean much. In the real world, C# will outperform JavaScript. One kilobyte payloads are pointless to benchmark. 1,024 bytes on a processor that is running at well over 1,000,000,000 Hertz. Even if you did a large unrolled loop where you did the same benchmark a million times before getting a number, you're far more likely to encounter some complicating factor that is beyond the scope of the benchmark. But, also, JavaScript has native support for JSON objects, so I'm not sure why you'd be using a library in the first place..