@Gblenn I'm aware of how speedtest works.
A VPN protocol could certainly be designed to work similarly by using multiple independent streams, which could be load-balanced by the router across multiple WANs, without the need for the router to decrypt any of the packets or even perform deep packet inspection to figure out it is VPN traffic. Or the VPN client could run on the router itself, be aware of the number of WANs, and appropriately split traffic for each. It would be a non-trivial implementation for sure, especially when the WANs have different performance characteristics, but it is certainly possible. There is research going on in this area, actually that I found yesterday while Googling, but can't locate right now. Clearly, this does not apply to the Wireguard protocol. I'm not sure if it applies to any other VPN protocol currently in existence.
Until such protocol is available, I would still like to be able to direct VPN traffic to the fastest WAN, and not the slower one, which is what I'm seeing occur. It's probably pure bad luck, but it is fairly consistent.
Right now, I have both load-balancing and failover configured for the 2 WANs. I could delete the load balancing rule, and have the fastest ISP be the top priority. But I would lose the aggregate bandwidth by doing so for applications that can benefit from it - the second ISP would only be used when the first one goes down.
Is there a way to keep the load balancing and failover, while causing Wireguard traffic to prefer one WAN over the other ?