A slow network is rarely the network. It is usually the Wi-Fi, the DNS, the proxy, the server, the application, or the database. The pattern that catches most slow-network reports: the network is fine, the user is on a bad Wi-Fi connection.
Table of contents
- Test the wired first
- Check the DNS
- Check the proxy
- Check the server
- Check the application
- Check the database
- FAQ
Test the wired first
The first thing to check: is the user on Wi-Fi? Wi-Fi is the most common cause of “the network is slow.” The pattern: the user is on Wi-Fi, the signal is weak, the throughput is low, and the user concludes the network is slow.
The fix: test the same workload over a wired connection. If the wired connection is fast and the Wi-Fi is slow, the problem is the Wi-Fi, not the network.
Check the DNS
The second most common cause is DNS. The pattern: the user types a URL, the DNS resolver is slow, the connection takes 5 seconds to start, and the user concludes the network is slow.
The fix: time the DNS resolution. dig +short on Linux or nslookup on Windows. If the resolution is taking more than 100ms, the problem is the DNS. The fix is usually a faster DNS resolver (1.1.1.1, 8.8.8.8) or a local cache.
Check the proxy
The third most common cause is the proxy. The pattern: the user is on a corporate network, all traffic goes through a proxy, the proxy is slow, and the user concludes the network is slow.
The fix: test the same workload outside the corporate network. If the workload is fast outside the corporate network and slow inside, the problem is the proxy. The fix is usually a faster proxy or a bypass for the specific workload.
Check the server
The fourth most common cause is the server. The pattern: the network is fast, the connection is fast, but the server is slow. The fix: time the server response.
A useful test: curl -w '%{time_total}' on Linux. If the time is spent in the connect phase, the problem is the network. If the time is spent in the TTFB phase, the problem is the server. If the time is spent in the download phase, the problem is the payload.
Check the application
The fifth most common cause is the application. The pattern: the network is fast, the server is fast, but the application is slow. The fix: profile the application.
A useful test: distributed tracing. OpenTelemetry, Jaeger, Datadog APM. The trace shows where the request is spending its time. The fix is usually in the application - a slow query, a slow external call, a slow garbage collector.
Check the database
The sixth most common cause is the database. The pattern: the network is fast, the server is fast, the application is fast, but the database is slow. The fix: profile the database.
A useful test: the database’s slow query log. PostgreSQL has pg_stat_statements, MySQL has slow_query_log. The slow query log shows which queries are taking the time, and EXPLAIN ANALYZE shows where the time is going. The fix is usually in the query - a missing index, a full table scan, a poorly-written join.
FAQ
Why is my network slow?
Usually not the network. The most common cause is the Wi-Fi (weak signal, contention, channel overlap), then the DNS (slow resolver), then the proxy (corporate proxy), then the server, the application, or the database.
How do I diagnose a slow network?
Test the wired first. If the wired is fast, the problem is the Wi-Fi. Time the DNS resolution. If the DNS is slow, the problem is the DNS. Time the server response. If the server is slow, the problem is the server. Profile the application. If the application is slow, the problem is the application.
What is the most common cause of a slow network?
Wi-Fi. A weak signal, contention from other devices, or channel overlap from a neighbor’s network. Test the wired first.
How do I speed up a slow network?
Move to a wired connection, use a faster DNS resolver (1.1.1.1, 8.8.8.8), bypass the corporate proxy if possible, profile the server, profile the application, profile the database.
If you are sizing a network tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The bandwidth, the latency, the CDN, the DNS - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual network performance in one place.