1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.
2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.
3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.
4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.
5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.
That sort of thing.
Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...
A trivial example is that a 'for' loop vs. 'while' loop can be faster on one browser compared to another.
These differences are even starker if you use newer features without polyfills. For example, 'forEach' implementations as of a year ago varied by orders of magnitude.
Native array sorting is another obvious one. Chrome, Firefox and especially Safari use quite different algorithms each based on array size with varying results.
If you add up all those little changes and always go with the option that's fastest in Chromium, in a reasonably complex SPA you could easily generate noticeable differences.
If 'for' and 'while' loops vary in speed that much between browsers, isn't that a defect in the browser? If one way is faster in chrome than firefox, why doesn't firefox change how it is doing the slower version?
Because that would likely mean slowing down a different scenario. It's usually a trade-off, not a "defect".
The array sorting is a great example where the length of the array chosen or the pre-sort ordering can affect which browser is faster. No single browser may be able to claim the fastest for every scenario.
I don't write JS-heavy websites these days so I don't have a technical example to give, but for instance I've opened the Vue cinema website recently on Firefox mobile. The thing was unusable - when I typed my postcode, nothing would show up on screen, the whole website seemed frozen while waiting to load something. I had to press several times certain buttons for something to happen.
On Chrome however everything worked fine right away. Overall it was just a few images, some text and a search bar, so no matter the performances of the browser that should work everywhere, but since it was probably only tested on Chrome and Safari, it only worked in these browsers.
1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.
2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.
3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.
4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.
5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.
That sort of thing.
Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...