I don't experience the 50% reduction but I'm only on 40/10 so that doesn't necessarily help.
Tested using Firefox 86.0 (64-bit) on Lubuntu 20.04 on a wired connection over a Fritz!box 7530.
I would suggest it's unlikely to involve the router as for IPv6, it only needs to route at layer 3 (IP) rather than NAT where it needs to modify the source TCP port (and IP) on the way out, and match this established flow on the reply.
So other than any added firewall rules it does not need any awareness that it is even web traffic let alone which browser you are using.
On Firefox one troubleshooting step should involve creating a new profile with the defaults for that version and no add-ons (especially ones which do content filtering such as ad or tracker blockers).
On Windows some internet security products can cause traffic to appear as if processed more in bursts than at a steady rate; Kaspersky was one I would have to temporarily disable before network speedtests.
In the general case IPv6 tries to avoid fragmentation and makes that solely the responsibility of the endpoints to simplify the routers workload by not having to break up into / re-assemble from fragments on route.
This is combined with an increased of the minimum MTU from 576 to 1280, so even if an endpoint is unable to determine the PathMTU it can send at 1280 without fragmentation.
The % difference in overheads between 1280, 1400 (Cloudflare
!) 1492 and 1500 is nowhere near enough to half the throughput so MTU can be dismissed without much consideration, unless you are tunneling IPv6 over IPv4 rather than native IPv6.
prlzx on Zen: FTTC (VDSL) at ~40Mbps / 10Mbps
with IP4/6 (no v6? - not true Internet)
Edited by prlzx (Thu 18-Mar-21 13:08:51)