Oh, it's just chromium with I'm guessing some questionable PGO choices and similar. I can't speak for blink/chromium, but as I spent most of a decade working o

Oh, it's just chromium with I'm guessing some questionable PGO choices and similar. I can't speak for blink/chromium, but as I spent most of a decade working on webkit and JSC, there are lots of trade offs for performance that can heavily benefit benchmarks without benefitting real web content. * First off PGO. You have to be very careful when you do profile guided optimization as you _could_ simply do nothing but do the profiling passes on benchmarks, but if you aren't testing actual web content you can pessimize actual page load performance (speedometer tries to be better at general browser perf than older benchmarks but you easily fall into a trap equivalent to making your browser the fastest at loading gmail but slower at yahoo mail :D) * A lot of modern browser performance comes as a result of caching policy, not in the download sense, but internal data structures. For example many years ago when I implemented bytecode caching in JSC (literally JS string source->bytecode) which saves you parsing and codegen time, but uses a lot of memory. A lot of the qualification for enabling that was "how much memory should be willing to burn in exchange for this performance", how time sensitive should the cache be, etc. Similarly you can get significant performance wins by making the GC heap large enough that you avoid sweeping during a benchmark. * Browsers also do a lot of event coalescing to try and minimize unnecessary dispatch costs, relayout, and repainting. You can generally adjust the coalescing policies and you can get good "performance" wins by increasing the coalescing windows, but the result can be perceivable lagginess and similar, but again it will help "performance" as measure by wall clock. There are many many trade offs beyond just these that impact performance, and those impact perceptual performance, wall time performance, memory usage (people complain about memory usage in modern browsers but you can improve wall time "performance" by increasing that even more), and power (which matters for any mobile device). It should not be a surprise that you can configure a chromium build (or gecko, or webkit) that can "out perform" the default configuration at some [set of] benchmark[s], but you should ask yourself why in a field as performance sensitive as browser and js engines the developers aren't already doing what you've done, and maybe the result of your changes is actually lower overall performance or otherwise worse user experience.