[aanm1988]

> In our case at Hunter, users were waiting on average 270ms for the handshake to be finished. Considering requests are handled in about 60ms on average, this was clearly too much.

Why? Did it hurt user engagement? Were people complaining the site was slow?

[kuschku]

The question is "is this the best we can do?".

If it’s no, then clearly we should improve.

[aanm1988]

By spending time and effort on things that may not actually matter?

To their credit this post talks about improving the performance, instead of just using it to complain about they can't use https because of a difference in a metric that may or may not actually cause end users any pain.

[kuschku]

You do realize that every latency you see on residential connections is magnified on mobile or even satellite connections?

If you have a RTT of seconds, 10 additional roundtrips can cost an entire minute.

These things become very noticeable very quickly if the system is in non-perfect environments.

Additionally, even with modern browsers it takes far too long to open a website — it should be 100% instant, less than one or two frames (16 or 33ms). That's not possible, as RTT is usually around 18ms between users and CDN edges, but at least it should be below perceivable delays (100ms).

EDIT:

My best websites hover around 281ms to start of transfer, and 400ms to the site being finished.

That's improvable, but most sites out there take literally half a minute to load.

Now go on a 64kbps connection, and try again. Handshake takes seconds, start of transfer is almost after 30sec, and by the time your website arrives your coffee has gone cold (a few minutes for a google search).

Years ago, Google was usable on dial-up. Now even the handshake takes as long as an entire search used to take. Notice anything?