Hacker News Reader

Comment by rebelde | Hacker News Reader

I really prefer to do what is best for my users: fast loading simple pages for users with slow connections on the other side of the world. (So, HTTP, not HTTPS.) But there is no sense fighting the powers that be.

EDIT: Thanks for the down votes! Unpopular thoughts like mine should be discouraged. Groupthink is best!

View on HN

https://istlsfastyet.com/

Of note:

TLS operational costs are still higher, right?

Not necessarily. Once you enable and optimize your TLS stack you're also well on your way to deploying HTTP/2. Unlike HTTP/1.1, HTTP/2 requires only a single connection per origin, which means fewer sockets, memory buffers, TLS handshakes, and so on. As a result, it may well be the case that you will be able to handle more users with fewer resources.

That applies to modern hardware and modern infrastructue – not to people in third world countries on decade old cheap hardware with barely working networks.

Decade old hardware can do TLS fine. Barely working networks can do TLS just as well as they can do non-TLS.

Barely working networks tend to use custom caching systems where TLS accesses often taken dozens of times longer.

They can always make the proxy explicit.

Then you need to be deploying HTTP/2 over TLS. You are doing a disservice to users with slow connections due to the cost of opening up multiple sockets. Multiplexing your data over an encrypted channel over HTTP/2 and TLS will be faster than domain-sharding over HTTP.

If it is a single HTML page with all CSS and important JS built in, I don't see how multiplexing will help the single page load faster.

That would also be very inefficient if you have more than 1 page with common CSS/JS, though.

Not OP but IME it can be faster, setting up multiple HTTP connections can be the bottleneck, YMMV a lot. That's why connections are one aspect of pageload metrics. Some sites are such that they'll only get ~1.something page-views per client per day.

See eg https://developer.yahoo.com/performance/rules.html#num_http=

> with all CSS and important JS built in

If your page is anything over a few KB in size you are really messing up then. Break CSS and JS into separate files so the browser can cache them and doesn't have to ask for them every single time the page is reloaded.

Often times its better to write them all inline - - if they are small of course. At least with http.

Http2 is different story.

Could you do HTTPS as default then offer to bump people to HTTP (and a slimmer site) if they want it? Do people with strong requirements for fast pages tend to use proxies that lighten the page (Opera used to have this built in) by reducing image sizes and such - presumably then it wouldn't matter if the original connection was HTTPS??

Would you mind sharing the site in question and the modal (ie most common) specs of your users devices?

Reply on news.ycombinator.com