tracert -4 google.com
tracert -6 google.com
I do get very different hops and latency.
However for “happy eyeballs” algo to fallback to IPv4, latency needs to be very bad on IPv6.
Especially for DNS, browsers don’t wait “very long” for the AAAA (v6) record to be resolved when they already have the A record (v4) and will start the v4 connection after at max 50ms (iirc thats the spec value, but imo it is too long and most browsers wait less I think).
The good news is that if the AAAA still arrives later it will be cached, thus this only affects the first connection to a site.
As for the actual v6 connection being slower (lets say both A and AAAA come from cache) the browser will start a v6 connection and only fall back to v4 if the connection isn’t established within some time (I think the spec says 250ms).
And to make this all more complicated HTTP1/2/3 enter the decision matrix. I.e. should the browser rather try v4/http3 than v6/http2? Opinions probably differ.
All of this is also on the critical path to a website loading for the user, thats why all of those waits cannot be too long. At some point the benefit of the better protocol will be outweighed by waiting. Even worse if the website doesn’t support v6 and the wait was for nothing.
For many years and even how there are networks that advertise they can do ipv6 and hand out real addresses but nothing works.
But in general, it's mostly because v4 and v6 can end up taking different routes. If an ISP has any BGP peers that are v4-only or v6-only then they can end up sending packets for the same host to different peers. In the worst cases, one of them can go to another country and back again. It's usually harder to get ISPs to fix this on v6 than it is on v4, because the problem is visible to fewer people (in part due to happy eyeballs itself).
For smaller websites, DNS caching can play a role. If there are fewer clients requesting AAAA records than there are clients requesting A records, there's a chance that a client requesting both will get a cached A record back quickly but have to wait for full resolution of the AAAA record. This is unlikely to happen for the most popular sites (because another client will probably have triggered the caching) or for the least popular sites (because the A record will also fall out of cache for those), but there'll be a band somewhere in the middle that's affected by this. There's enough v6-capable clients around these days that I doubt this has a major impact now, but it's interesting that caches can cause unfairness like this.
[1] https://www.google.co.uk/intl/en/ipv6/statistics.html#tab=pe...