Server Time vs Network Time: Why a Site Feels Slow
Published: 2026-10-20 16:10 (UTC+8) | Data as of: 2026-10-20 | Source: Zhilianhai site measurements
Split the two times first
What users call "slow" is the sum of two numbers: server generation time and network time. Mixing them in one discussion guarantees you optimise the wrong layer.
| Measure | How | Healthy |
|---|---|---|
| Server time | curl -w %{time_starttransfer} from the server to itself | 10–100 ms |
| Network time | Same URL from a real client | Server time plus one or two round trips |
If the server answers in 19 ms locally and 2600 ms from outside, the code is not the problem. Stop tuning PHP.
Then look at the handshake
The TLS handshake is a separate cost. We have measured cases where the TCP connection took 7 ms and the TLS handshake took 1.6 seconds. Three usual causes:
- Incomplete certificate chain: only the leaf certificate is served, so clients fetch the intermediate themselves.
- No HTTP/2: without ALPN negotiating h2, dozens of static assets fall back to a handful of serial connections.
- Cross-border routing: a domestic node answers in tens of milliseconds, a foreign node can take hundreds, with high variance.
Then count requests
A content page should stay under about forty requests. Above sixty, look at how finely the CSS and JS are split: every <link> and <script> is another round trip. Merging stylesheets is the safest reduction because it changes only transport, not cascade order.
Compression and prefetch come last
- gzip or brotli: always on for text; a 300 KB HTML page commonly compresses to 44 KB.
- Static caching: give
/assets/and image directories a thirty-day max-age. - Speculative prefetch: fetch the next page when the pointer hovers a link, making the click feel instant.
A counter-example
We once chased a page that took eight seconds. The cause was a retired footer module still rendered server-side: eight icon images plus a QR generator endpoint, each around five seconds. Removing the module from the server output cut the load time below seven seconds before any other optimisation mattered.
Delete what is unused before optimising what is used.
When a CDN is the only answer
Once server time is under 100 ms and request count and weight are reasonable, yet external tests remain slow, the remaining cost is the path. At that point local optimisation is exhausted and only a CDN or a nearby node can help.
See about us, the company directory, or contact us.
Zhilianhai