That's only because it was the "Chrome" (i.e. the dominant browser). Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up.
> I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.
(While this may seem like poetic justice, Google's also been doing this against everyone else, so we shouldn't cheer. Also, unlike when Microsoft pulled these stunts, this might not even be deliberate on the part of the Google webdevs.)
YouTube did this to Firefox too - for a while they were serving a special degraded version of YT to Firefox users (polyfilled web components, instead of native web components or their classic non-web-components version) even though they had versions that would perform better. "Oops".
If you used user-agent tricks you could get them to serve a good version.
There will always be a case that kicks you out of the fast path, but shouldn't (or a case where you take the fast path incorrectly, resulting in incorrect behaviour). This is a corollary of Rice's theorem.
