Hacker News Reader

Comment by ed25519FUUU | Hacker News Reader

Unless your web traffic represents single or double digits of worldwide web traffic, I don't see why anyone would bother.

View on HN

Well good thing it's optional and really only useful for a small subset of very large websites. I still serve my simple static unminified websites, but that doesn't mean minification and other optimizations have no reason to exist.

Now you got my head all going, doing bad math.... As I simply wanted to write "That is not very 'green' of you" as in, compressed, minified, could be more efficient, better for the environment. But then I started thinking, is the saved traffic worth the compress (though once for static content) and decompress at all clients, increased cpu power, worth that trade off...

And I guess I am not the first person to wonder about this, any people wanting to share a bookmark/url, tia (so I don't have to use google... ;) )

I don't think _you_ (nor I in my personal capacity) would, but your provider definitely should, and then you get the benefit.

So if you're hosting via some accelerator like Cloudflare, AWS API Gateway, whatever Google has in this space, or app host like Heroku and friends, they'll happily do the work because they get the aggregate benefit. Your own site will become marginally faster or have happier roaming users, and so on, essentially for free.

When you're developing a generic website, I don't think you should care about this. When you're self-hosting, you can decide if it might be worth it or not. It probably won't be worth the effort unless you're doing something really intricate or special, in which case you'll be really happy that you have the option.

Just like minified JS, I expect people will run 3 in production, and 2 in development/etc environments.

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

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.

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.

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

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.

Reply on news.ycombinator.com