Maybe placebo effect, but I’ve found these sorts of issues disappear when I pump everything through a Wireguard connection (so all TCP is handled locally and multiplexed into UDP packets sent on the outbound connection).
Last time it happened was an `npm install` of a large repo that was stalling during parallel download step. This is on a 500mbps wired connection (though admittedly with a router that has some known issues with TCP congestion). When I enabled Wireguard the problem disappeared and the install completed with no choking.
One thing I've often done for home/soho wifi setups is to use more narrow bands... instead of whatever the max signal band size is, I'd use a step down. This has generally resulted in a more consistent and stronger connection. It may not have as much max throughput in theory, but the experience has usually been much better.
Yep, one perhaps counterintuitive thing is even when there is a flat level of noise across a 80 MHz of spectrum and a single client connecting when the client is connected at 20 MHz instead of 80 MHz the signal to noise ratio will be 4x better. There are other benefits to shrinking the bands as well, particularly because interference is rarely just flat across the entire band.
The other big thing to do is disable the lowest basic data rates. Certain frames from the AP must always transmit at the lowest speed a client can be connected at and sometimes it's better to just let the client at the far edge lose connection than try to hold on to a poor connection at the detriment of everyone else with a good connection. Concepts like "airtime fairness" (or different jargon depending on the AP) also help prevent laggards from unduly tanking everyone.
