|
|
|
|
|
by 10000truths
213 days ago
|
|
The table is a bit misleading. Most of the resources of a website are loaded concurrently and are not on the critical path of the "first contentful paint", so latency does not compound as quickly as the table implies. For web apps, much of the end-to-end latency hides lower in the networking stack. Here's the worst-case latency for a modern Chrome browser performing a cold load of an SPA website: DNS-over-HTTPS-over-QUIC resolution: 2 RTTs TCP handshake: 1 RTT TLS v1.2 handshake: 2 RTTs HTTP request/response (HTML): 1 RTT HTTP request/response (bundled JS that actually renders the content): 1 RTT That's 7 round trips. If your connection crosses a continent, that's easily a 1-2 second time-to-first-byte for the content you actually care about. And no amount of bandwidth will decrease that, since the bottlenecks are the speed of light and router hop latencies. Weak 4G/WiFi signal and/or network congestion will worsen that latency even further. |
|
The user no longer has to connect to the central app server, they can connect to their nearest cache edge box, which is probably a lot closer to them (1-10ms is typical).
Note that stateful API calls will still need to go back to the central app server, potentially an intercontinental hop.