The book "High Performance Browser Networking" from Ilya Grigorik answers exactly this. There is a whole chapter (7th) dedicated to mobile networks. The book states that the problem with high performance is almost always tied to latency, we usually have plenty of bandwidth but the protocols gets in the way. Be it TCP slow start, the Radio Resource Controller (RRC) or suboptimal configurations. If you are experiencing poor latency only in mobile networks it's the way they are designed.
There is a table in the book about typical latencies:
Table 7-2. Data rates and latency for an active mobile connection
Generation | Data rate | Latency
2G | 100–400 Kbit/s | 300–1000 ms
3G | 0.5–5 Mbit/s | 100–500 ms
4G | 1–50 Mbit/s | < 100 ms
Although very relevant to latency the TCP characteristic three-way handshake or the slow-start don't really answer the question, as they affect wired connections equally. What does really affect the latency in mobile networks is the layer under IP. If the layer under IP has a latency of half a second, a TCP connection to a server will take ~1.5 sec (0.5s*3), as you see the numbers add up pretty quick. As said before that's supposing that the mobile is not idle. If the handset is idle it first has to "connect" to the network, that requires to negotiate a reserve of resources with the tower (simplified), and that takes between 50-100ms in LTE, up to several seconds in 3G, and more in earlier networks.
Figure 7-12. LTE request flow latencies
- Control plane latency: Fixed, one-time latency cost incurred for RRC negotiation and state transitions: <100 ms for idle to active, and <50 ms for dormant to active.
- User plane latency: Fixed cost for every application packet transferred between the device and the radio tower: <5 ms.
- Core network latency: Carrier dependent cost for transporting the packet from the radio tower to the packet gateway: in practice, 30–100 ms.
- Internet routing latency: Variable latency cost between the carrier’s packet gateway and the destination address on the public Internet.
In practice, the end-to-end latency of many deployed 4G networks tends to be in the 30–100 ms range once the device is in a connected state.
So, you have for one request (Figure 8-2. Components of a "simple" HTTP request):
- RRC negotiation 50-2500 ms
- DNS lookup 1 RTT
- TCP handshake 1 RTT (preexisting connection) or 3 RTT (new connection)
- TLS handshake 1-2 RTTs
- HTTP request 1-n RTTs
And with real data:
Table 8-1. Latency overhead of a single HTTP request
| 3G | 4G
Control plane | 200–2,500 ms | 50–100 ms
DNS lookup | 200 ms | 100 ms
TCP handshake | 200 ms | 100 ms
TLS handshake | 200–400 ms | 100–200 ms
HTTP request | 200 ms | 100 ms
Total latency overhead | 200–3500 ms | 100–600 ms
In addition if you have a interactive application that you want to perform moderately ok in a mobile network you can experiment disabling the Nagle algorithm (the kernel waits for data to coalescence into bigger packets instead of sending multiple smaller packets) look for ways to test it in https://stackoverflow.com/a/17843292/869019.
There is the option to read the entire book for free by everyone at https://hpbn.co/ sponsored by Velocity Conference. This is a very highly recommended book, not only to people developing websites, it is useful to everyone who does serve bytes over some network to a client.