5 ms·

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.

by rebelde 10y ago

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!

Walkman 10y ago
https://istlsfastyet.com/ https://istlsfastyet.com/
- lallysingh 10y ago
  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.
- kuschku 10y ago
  That applies to modern hardware and modern infrastructue – not to people in third world countries on decade old cheap hardware with barely working networks.
  - Dylan16807 10y ago
    Decade old hardware can do TLS fine. Barely working networks can do TLS just as well as they can do non-TLS.
    - kuschku 10y ago
      Barely working networks tend to use custom caching systems where TLS accesses often taken dozens of times longer.
      - Dylan16807 10y ago
        They can always make the proxy explicit.
mark242 10y ago
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.
- rebelde 10y ago
  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.
  - untog 10y ago
    That would also be very inefficient if you have more than 1 page with common CSS/JS, though.
    - pbhjpbhj 10y ago
      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= https://developer.yahoo.com/performance/rules.html#num_http=
  - pbhjpbhj 10y ago
    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?
  - pixl97 10y ago
    > 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.

by rebelde 10y ago

Walkman 10y ago

https://istlsfastyet.com/ https://istlsfastyet.com/

lallysingh 10y ago
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.
kuschku 10y ago
That applies to modern hardware and modern infrastructue – not to people in third world countries on decade old cheap hardware with barely working networks.
- Dylan16807 10y ago
  Decade old hardware can do TLS fine. Barely working networks can do TLS just as well as they can do non-TLS.
  - kuschku 10y ago
    Barely working networks tend to use custom caching systems where TLS accesses often taken dozens of times longer.
    - Dylan16807 10y ago
      They can always make the proxy explicit.

mark242 10y ago

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.

rebelde 10y ago
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.
- untog 10y ago
  That would also be very inefficient if you have more than 1 page with common CSS/JS, though.
  - pbhjpbhj 10y ago
    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= https://developer.yahoo.com/performance/rules.html#num_http=
- pbhjpbhj 10y ago
  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?
- pixl97 10y ago
  > 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.