3 ms·

You're being downvoted because a large segment of HN is engineers who prefer sites like http://motherfuckingwebsite.com http://motherfuckingwebsite.com and http

You're being downvoted because a large segment of HN is engineers who prefer sites like http://motherfuckingwebsite.com http://motherfuckingwebsite.com and http://evenbettermotherfucking.website http://evenbettermotherfucking.website Basically, what it comes down to is that if all 37 requests are done in parallel, then you're only loading the page as slowly as the slowest. Sadly, this is rarely the case. Most browsers will only make 6 concurrent requests from a server, which you can see in Firefox via the about:config page and the network.http.max-persistent-connections-per-server. Worse, some of that JS is probably downloading more JS, which means that you will have multiple requests going out. On mobile, this means you're running 8-30 second delays for each "group" of requests, especially if you have poor reception. Good news is that after that initial latency, the actual transfer should go fairly fast. On the other hand, a social commenting program should need at a minimum 1 JS file, 1 CSS file, 1 for the actual data (3 comment texts, 3 base64 encoded profile pics at a small resolution). So FB is running at ~30x the optimum (87 assets, of which 35 are JS). If you think it's not that big a deal, I'd suggest taking a trip abroad or just out to some smaller towns in your area, and really experience why users feel the internet has not really gotten faster since the 90s (keeping in mind users don't care about data size, they care about latency).

deleted 9y ago
[deleted]
noir_lord 9y ago
Agreed with everything you said except > keeping in mind users don't care about data size, they care about latency. Users do care about data size since there are still a lot of people on data limited contracts even in the UK which has a fairly healthy mobile market. What people don't necessarily realise is the connection between the two, I'd quite like it if the mobile browsers had a running total of the total amount of data transferred in that tab on each new visit/refresh. I'm a programmer and I still don't know which pages are heavy or not (given fixed bandwidth the time to interaction would be a clue but mobile internet latency is all over the map so you can't tell if it's a big site/page or just the mobile internet shitting the bed).
- steventhedev 9y ago
  You are quite correct. Data caps do make users concerned with the amount of data transferred, but only post hoc, or as a proxy for latency. Thinking about it, there's got to be a plugin for firefox/chrome that show the data size of each page. For mobile, you can install firefox which allows you to install plugins (pretty much essential for blocking ads in mobile browsing).
  - noir_lord 9y ago
    I use Chroma Android variant and it has the option to show inbound/outbound traffic on the status bar updated a few times per second (and finally battery state as an actual percentage) that stupid little battery picture is bloody useless (hmm, it's just below halfway, so around 45% I guess..checks 27%..bad UX). For me that is enough, if I load a page and see it sit at 200kb/s for more than a second or two I'll often nuke the page. I have 1Gb of data on my phone package (simply don't use mobile data much, I have unlimited fiber at home and the office).
korzun 9y ago
> Basically, what it comes down to is that if all 37 requests are done in parallel, then you're only loading the page as slowly as the slowest Doesn't apply here. Facebook is using async and downgrades the experience for mobile clients. > Most browsers will only make 6 concurrent requests from a server, which you can see in Firefox via the about:config page and the network.http.max-persistent-connections-per-server. The limitation is per host not per server. > On mobile, this means you're running 8-30 second delays for each "group" of requests, especially if you have poor reception. We are talking about an asynchronous implementation. > On the other hand, a social commenting program should need at a minimum 1 JS file, 1 CSS file, 1 for the actual data (3 comment texts, 3 base64 encoded profile pics at a small resolution). So FB is running at ~30x the optimum (87 assets, of which 35 are JS). That's the payload for the desktop clients. Furthermore, try finding a website that follows 'the optimum' standard you are describing. > If you think it's not that big a deal, I'd suggest taking a trip abroad or just out to some smaller towns in your area, and really experience why users feel the internet has not really gotten faster since the 90s (keeping in mind users don't care about data size, they care about latency). If you are still using 90's technology, you won't be able to consume most of the current websites. An asynchronous widget will not be the 'breaking point,' far from it. The scenarios you are describing will not trigger the loading of these widgets.
- graphememes 9y ago
  > Per host not per server You are correct, but I will be a little more terse with words, per hostname (domain). There is also a max connections limit as well which is generally 10-17. 2014: http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-to-same.html http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-co... Today: http://www.browserscope.org/?category=network&v=top http://www.browserscope.org/?category=network&v=top

deleted 9y ago

[deleted]

noir_lord 9y ago

Agreed with everything you said except > keeping in mind users don't care about data size, they care about latency. Users do care about data size since there are still a lot of people on data limited contracts even in the UK which has a fairly healthy mobile market. What people don't necessarily realise is the connection between the two, I'd quite like it if the mobile browsers had a running total of the total amount of data transferred in that tab on each new visit/refresh. I'm a programmer and I still don't know which pages are heavy or not (given fixed bandwidth the time to interaction would be a clue but mobile internet latency is all over the map so you can't tell if it's a big site/page or just the mobile internet shitting the bed).

steventhedev 9y ago
You are quite correct. Data caps do make users concerned with the amount of data transferred, but only post hoc, or as a proxy for latency. Thinking about it, there's got to be a plugin for firefox/chrome that show the data size of each page. For mobile, you can install firefox which allows you to install plugins (pretty much essential for blocking ads in mobile browsing).
- noir_lord 9y ago
  I use Chroma Android variant and it has the option to show inbound/outbound traffic on the status bar updated a few times per second (and finally battery state as an actual percentage) that stupid little battery picture is bloody useless (hmm, it's just below halfway, so around 45% I guess..checks 27%..bad UX). For me that is enough, if I load a page and see it sit at 200kb/s for more than a second or two I'll often nuke the page. I have 1Gb of data on my phone package (simply don't use mobile data much, I have unlimited fiber at home and the office).

korzun 9y ago

> Basically, what it comes down to is that if all 37 requests are done in parallel, then you're only loading the page as slowly as the slowest Doesn't apply here. Facebook is using async and downgrades the experience for mobile clients. > Most browsers will only make 6 concurrent requests from a server, which you can see in Firefox via the about:config page and the network.http.max-persistent-connections-per-server. The limitation is per host not per server. > On mobile, this means you're running 8-30 second delays for each "group" of requests, especially if you have poor reception. We are talking about an asynchronous implementation. > On the other hand, a social commenting program should need at a minimum 1 JS file, 1 CSS file, 1 for the actual data (3 comment texts, 3 base64 encoded profile pics at a small resolution). So FB is running at ~30x the optimum (87 assets, of which 35 are JS). That's the payload for the desktop clients. Furthermore, try finding a website that follows 'the optimum' standard you are describing. > If you think it's not that big a deal, I'd suggest taking a trip abroad or just out to some smaller towns in your area, and really experience why users feel the internet has not really gotten faster since the 90s (keeping in mind users don't care about data size, they care about latency). If you are still using 90's technology, you won't be able to consume most of the current websites. An asynchronous widget will not be the 'breaking point,' far from it. The scenarios you are describing will not trigger the loading of these widgets.

graphememes 9y ago
> Per host not per server You are correct, but I will be a little more terse with words, per hostname (domain). There is also a max connections limit as well which is generally 10-17. 2014: http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-to-same.html http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-co... Today: http://www.browserscope.org/?category=network&v=top http://www.browserscope.org/?category=network&v=top