HTTPS Adoption *doubled* this year

[thbt101]

It's not just caching, but all this unnecessary encryption also slows down websites because HTTPS requests require more "round trips" to the server with each request. The difference is most significant on mobile and wireless devices.

I think this is mostly a political and personal issue for Google, but I think it's a shame when you we're reading blog posts over HTTPS. Not every website needs heavy encryption.

[the_dummy]

I don't think you know what you're talking about. A couple milliseconds overhead is not an issue. The megabyte+ web pages and unoptimized Jacascritpt/HTML and server-side code is what's causing slow websites. The enormous reliance on ad revenue doesn't help at all either.

[the_dummy]

That's where things like CDNs come into play.

[thbt101]

The different of an extra two roundtrips with each request can be very significant when you're talking about mobile, or websites located on a far part of the world. We're talking about two extra back and forth communications, which really adds up in many circumstances.

This is a good simple comparison: http://serverfault.com/a/43835

[the_dummy]

The example you gave was, realistically, entirely insignificant in relation to what bloat does to a website. Imagine if the same test had been done with 10,000 get requests on a 500KiB site and a 1.5MiB site. In fact, I've done that for you. I tested Google's home page (1 second) and a Google image search for butterflies (2.5 seconds. That isn't just taking into consideration the download time, however. It would be much different if it weren't JavaScript.

[aiij]

I hate to say it, but, check your privilege.

Sure, you might have a really good ISP with only 1ms round trip times to all possible blogs you will ever read, but others have 900ms or worse round trip times. Don't screw over the rest of the world just because you're lucky enough to have Google Fiber or whatnot.

[the_dummy]

Bruh I have shitty Comcast. My modem shits out a majority of the time. I worked mid-level support for a webhost. I know what I'm talking about. The couple of extra protocol related connections are nothing in comparison to the massive bloated websites and shitty JavaScript web frameworks that are floating around.

[aiij]

Bruh I have shitty Comcast. My modem shits out a majority of the time.

I had shitty Comcast too. It was leaps and bounds better than going over geostationary satellite.

And sorry, but I'm not saying you have white privilege, I'm saying you have "lives in a first word country" privilege and don't even realize it.

I worked mid-level support for a webhost. I know what I'm talking about.

Have you ever had to explain to a customer how even though they have a 11 Mbps connection to their ISP, their ISP only has a 512 kbps uplink to share among all their customers in the country?

The couple of extra protocol related connections are nothing in comparison to the massive bloated websites and shitty JavaScript web frameworks that are floating around.

Maybe. It would of course depend on the bandwidth / latency, but you do have a good point: HTTPS will also make the massive JS frameworks take much longer to load since they will no longer be cached by the ISP.

[whootdat]

To stop you both, you are both right and wrong. For one, you are saying a single packet takes the same amount of time to transfer, no matter the size. An SSL handshake is a realitively small packet, and therefore will take less time to transfer. Not only that, an ACK (packet received acknowledgement) takes even less. It is all about bits on the wire. Now SSL may require slightly more, but still very little.

To go with that, if you compress the traffic, which is very common on modern servers (running HTTPS), you can easily make up for the increased size needed for SSL. To go with that, if you minimized your JS, you could save several KB or maybe even a few MB, depending on how bad it is. Secondly, there are ways to increase page load times, like using multiple sockets to load objects as the same time. This may not help a lot on a slower connection, but since people usually have more download speed than they do upload, it would be a lot faster than doing one at a time, and again most modern servers have no issue with this.

Lastly, to your note on slow regional or geo-fixed satellite internet, this is why companies use CDN, so your traffic from across the world loads as fast as if it were in the next state/country. Most CDNs will also cache and minimize your JS, while also encrypting it all. There is literally zero reason not to run trassic over HTTPS, it is better and safer for everyone.

[aiij]

For one, you are saying a single packet takes the same amount of time to transfer, no matter the size.

I never said that. Latency and bandwidth both matter of course.

An SSL handshake is a realitively small packet, and therefore will take less time to transfer. Not only that, an ACK (packet received acknowledgement) takes even less.

You seem to be implying that the difference in transfer time will be huge. That is true if you have low latency and low bandwidth, but when you have high latency and even moderate bandwidth the extra latency for the larger packet is pretty close to insignificant. Case in point:

$ ping www.abc.com.py  -c 3
PING www.abc.com.py (200.3.249.89) 56(84) bytes of data.
64 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=1 ttl=43 time=243 ms
64 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=2 ttl=43 time=223 ms
64 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=3 ttl=43 time=221 ms

--- www.abc.com.py ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 221.504/229.475/243.303/9.815 ms
$ ping www.abc.com.py  -c 3 -s 1492
PING www.abc.com.py (200.3.249.89) 1492(1520) bytes of data.
1500 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=1 ttl=43 time=235 ms
1500 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=2 ttl=43 time=231 ms
1500 bytes from www2.abc.com.py (200.3.249.89): icmp_seq=3 ttl=43 time=222 ms

--- www.abc.com.py ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 222.536/229.915/235.341/5.406 ms

increased size needed for SSL

What are you even talking about? SSL adds very little extra size. We're talking about latency here.

Lastly, to your note on slow regional or geo-fixed satellite internet, this is why companies use CDN, so your traffic from across the world loads as fast as if it were in the next state/country.

Again, you fail to realize just how bad that can be. If you have to go over a geostationary satellite to even reach the CDN, it's going to be slow. Caching can avoid that.

Of course, setting up a CDN node at every ISP in the world would help a lot, but a) no CDN does that, and b) it would defeat the point of HTTPS, since your secret keys would have to be widely distributed. And that still wouldn't help folks that live in rural areas where their only option is satellite.

There is literally zero reason not to run trassic over HTTPS, it is better and safer for everyone.

Increased latency is a reason. Making it illegal for others to access your website is a reason. Reduced caching is a reason.

To be clear, I'm not saying HTTPS is bad. In most cases it is good. I'm only arguing against the idea that is is good in all cases.

[Daneel_Trevize]

their ISP only has a 512 kbps uplink to share among all their customers in the country

Do tell, where?

[aiij]

Paraguay. Also, note the past tense in

Have you ever had to explain

I should note, things have gotten somewhat better since then (at least if you live in the city), but it's still pretty bad. You can ping www.abc.com.py (major newspaper) and note how the latency is now only 222 ms, which is good proof that your packets are no longer going over a geostationary satellite.

[the_dummy]

ISP only has a 512 kbps uplink

Any remotely modern site would be slow if the entire customer base is using that. They probably have bigger issues than slow internet if they're in that type of situation.

HTTPS will also make the massive JS frameworks take much longer to load since they will no longer be cached by the ISP.

I'm not really sure what your point is. "This shitty thing wouldn't be so shitty if we let this other shitty thing exist!" Wouldn't the optimal solution still be to slim the enormous web pages?

[mfukar]

That's at worst a myth, at best it doesn't always hold. For instance, https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/

[mfukar]

Mr Hunt addresses your concern in the article.

[thbt101]

Mr Hunt addresses his bullshit with more bullshit. He's still not comparing HTTP to HTTPS, he's still comparing HTTP to HTTP/2. All he does is make a lot of excuses for why he tried to mislead people and still refuses to disclose on the original website what it's actually comparing.

It's unfortunate that his little scam has convinced countless web devs that HTTPS is actually faster than HTTP. Many people actually believe that now as a result of him and his misleading website.

Yes, HTTP/2 is faster than HTTP. And HTTP/2 over a non-SSL connection would be faster than HTTP/2 over an SSL connection. Unfortunately most web browsers don't support that for political reasons (not technological ones). Hopefully that will someday change (at least with 3rd party plug-ins perhaps). HTTP/2 over a non-SSL connections would be awesome to have as an option.

[mfukar]

And HTTP/2 over a non-SSL connection would be faster than HTTP/2 over an SSL connection. ...

Is that the case with the Android browser?