[3pt14159]

So I'm more of a machine learning / cyber security guy than a sys admin, but with that proviso, here is my understanding:

Of course you'll have to check your own site for your own performance issues, but while travelling from Toronto to Vilnius I found our site much slower and investigated why. We have a webapp running Ember with mix of largish assets, like images, and smallish assets, talking to a JSON API standard API written in rails and proxied through nginx (responses are usually around 1kb of JSON, but this gets compressed with HTTP2).

In reality waiting 200ms is an enormous cost and carries a hidden cost: Larger packets are easier to lose. If you're going mostly to browsers that is more and more often going through wifi or cell tower networks with at least 1% packet loss and when the resend happens you're stuck with that 200ms delay again.

That's my understanding, but the real truth is "it just works for me when testing around the world with real-world use cases, try testing it out yourself and please let me know if you learn something new".

[the8472]

Nagle's algorithm is not a network level delay. If data is lost then it is retransmitted as soon as the sender learns about the loss. Nagle only delays application level sends.

The problem with webapps is a compounding effect of many requests.

a) dependency chains (asset A loads B loads C) mean the browser only knows to load C once B has been loaded, so the latencies (including nagle) add up. http/2 push is supposed to help with that.

b) statistics. your 95th percentile latency is irrelevant if you're loading hundreds of assets and want to know when the site has finished loading.