4 ms·

Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-

by timr 8y ago

Unless your user is sitting in the same datacenter as the app, there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip. Pinging google.com from my current connection (NYC) results in an average 26ms latency. Facebook is 25ms. That's just baseline connection latency for a user in a place with a solid connection, and you're unlikely to do better. Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. The way you improve responsiveness is by eliminating round-trips, not assuming that client-side frameworks will save you.

k__ 8y ago
I get a <50ms ping to AWS datacenters in my country.
delinka 8y ago
"...there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip." Which is why the comment is advocating for locally-cached resources. "The way you improve responsiveness is by eliminating round-trips..." Hence "preload" above.
- timr 8y ago
  Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.
jlg23 8y ago
> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand. And I am painfully aware that the bottleneck is the code, not the network.
- timr 8y ago
  Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed. But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
  - jlg23 8y ago
    150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).
    - timr 8y ago
      Yes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages. I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.

by timr 8y ago

k__ 8y ago

I get a <50ms ping to AWS datacenters in my country.

delinka 8y ago

"...there is almost no chance that you're getting a 50ms latency on any action that requires a round-trip." Which is why the comment is advocating for locally-cached resources. "The way you improve responsiveness is by eliminating round-trips..." Hence "preload" above.

timr 8y ago
Frameworks don't make your code smart. Writing a webapp that aggressively preloads without causing problems is hard, and while frameworks give you some tools to make that easier, they don't do the hard work for you.

jlg23 8y ago

> Realistically, most apps that aren't Google scale are lucky to get 300ms average latency. I am hosting a quite popular site built with perl and php over 20+ years and with at least 2 round-trips to the DB per request. 150ms latency triggers a warning in monitoring, 200 is considered "critical". The site sits on the west coast, the monitor in Chicago. The site serves at least 10 concurrent clients at any time (read: 5am) up to a few thousand. And I am painfully aware that the bottleneck is the code, not the network.

timr 8y ago
Honestly, it sounds like you're set up better than 95% of the webapps I've encountered (and I'm including some big, famous names in that list). Big, well-resourced dev teams make the mistake of assuming that "works on my box" is the definitive measurement of site speed. But also, let's be real for a moment: define "latency". Is 150ms your (client-measured) connection time? Your render time? Your usable-page time? Again, most webapps are lucky to get HTML back to the user in under 300ms, and if your 150ms metric is "time to server-side render", then you very likely aren't.
- jlg23 8y ago
  150ms are client-side read. But without any js-triggered modifications to the DOM tree, this is pretty much the render time (rendering is 2ms on my not-too-beefy laptop).
  - timr 8y ago
    Yes, that's quite good. It's pretty common to find server-side actions that take longer than 150ms to just return the page, and 2ms render times absolutely smoke most JS-framework pages. I stand by my original comment (it's better to avoid loads than to assume you're fast), but good on you for getting those latencies down.