Hacker News Reader

Comment by baggy_trough | Hacker News Reader

You would bother if you wanted reduced latency for a better user experience.

Optimising at that granularity is also utterly at odds with everything that webdev has been doing for decades now.

It's a micro optimisation that won't even register for your users, especially if you're reducing latency on 2mb of JS bundles

Well those webdevs are terrible, but that doesn't mean everyone has to follow what they are doing.

I don't disagree, but I still really really have a hard time caring about < 1ms of latency on a 50ms call.

But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.

That 1 ms translates to a much larger number in poor countries with everyone on 2G.

I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.

It's really the packet loss and TCP backoff that's a killer.

If you wanted reduced latency, I think you would stick with HTTP/2 with onload on a Solarflare card.

Until there is dedicated hardware NICs I think you would find HTTP/3 has worse latency. That is until dedicated NIC accelerators come out on the market.

You're still stuck with TCP and its backoff algorithm in that case though.

It would bother me if I had to debug an issue with QUIC for a website that never needed it in the first place.

Reply on news.ycombinator.com