Quick analytical take, trying not to repeat what @nachtschatten and @himmelsjager already covered:
-
One thing they did not poke at hard: bufferbloat
If your line has bad bufferbloat, even tiny uploads (telemetry, chat, cloud sync) can nuke speed tests randomly.
• Run a test on a site that explicitly measures bufferbloat and look at latency under load.
• If idle ping is low but latency explodes during download or upload, the problem is likely queueing, not pure WiFi.
Fix is usually: enable SQM / “Smart Queue Management” or “FQ_Codel / Cake” on a capable router, or replace a very cheap ISP router. -
Ignore raw “link speed” from your device for now
People see “866 Mbps” or similar and assume WiFi is fine. That figure is theoretical PHY rate, not throughput. If it oscillates wildly while you sit still, that hints at interference or power-save quirks, but a stable high number does not guarantee clean performance. Judge by:
• Consistency of large file copies on your LAN.
• Jitter and packet loss, not just Mbps peaks. -
About NetSpot specifically
Since channel crowding and bad placement keep coming up, NetSpot can be useful beyond generic “WiFi analyzer” apps:
Pros:
• Better visual heatmaps than most free phone apps.
• Helps you correlate weak spots with construction (walls, corners) instead of guessing.
• Nice for verifying after-the-fact that a change of channel or router position really helped.
Cons:
• Desktop focused, not as quick as a basic phone scanner when you just want a 10‑second look.
• Some features are overkill if you only have a small apartment and one router.
• You still need to understand what you are seeing; the app does not magically pick settings for you. -
Where I slightly disagree with the others
They both correctly emphasize turning off “smart” features like band steering for testing. I would add: after you stabilize things, it can be worth re‑enabling band steering on a modern router to avoid your phone sticking to 2.4 GHz halfway across the house. The key is:
• First, prove that your instability is not caused by steering.
• Later, re‑enable it and see if behavior actually improves day to day. -
Don’t reset everything at once
It is tempting to jump straight to factory reset, new channels, new SSID names, firmware upgrades, all at the same time. That makes it impossible to know what actually fixed it. Instead:
• Change one variable per test session (for example, force a non‑DFS 5 GHz channel, then leave it that way for a while).
• Take screenshots or quick notes of each configuration step.
If you ever need to revert, or if results get worse, you will not be stuck wondering which tweak did it. -
Actionable next move
Given what you already tried:
• Use a bufferbloat‑aware test and a few pings to see if latency under load is the real villain.
• Run a quick survey with NetSpot or a similar tool to see whether you are sitting in the middle of several competing APs on the same channels.
• Change only channel and power level first, then worry about advanced toggles like QoS or band steering.
Combine those with the structured testing @himmelsjager laid out and the practical interference checks from @nachtschatten. That mix usually gets you from “random chaos” to a specific, boring root cause you can either tune around or fix with newer hardware.