4 ms·

This is awesome, and actually a pretty neat way of evaluating websites. A surprising number of people are still on low bandwidth connections, while it's probab

This is awesome, and actually a pretty neat way of evaluating websites. A surprising number of people are still on low bandwidth connections, while it's probably not reasonable to optimize for them, it's at least worth considering that market occasionally.

adrianN 10y ago
If you optimize for people on low bandwidth connections, you automatically also optimize for those with limited mobile data. And as a bonus, your website becomes faster for everybody with a fat pipe too.
- vortico 10y ago
  "Optimize" is somewhat the wrong word. "Straying from temptation" would be more accurate, since all garbage on webpages is placed there by a website manager's overzealous want to increase popularity or profit.
  - rtpg 10y ago
    I understand some people don't use things like cloud software, but the internet isn't just blogs and newspaper websites. Sometimes styling is added to make web app UX better. Sometimes Javascript is used so that, even if the first load takes more time, subsequent actions will use less bandwidth. Sometimes more stuff is put on the page because 95% of users want that information to also show up. This is obvious and pedantic, but also counters half of the comments on these sorts of these stories
    - vortico 10y ago
      My point especially applies to web apps. I just loaded facebook.com, and it took 228 requests, 8,825 KB, and 17.0 s. Scrolling through the page is laggy while a stressful amount of muted videos start playing and mouse-hover events start firing. Compare this with mbasic.facebook.com, which is 22 requests, 107 KB, and 1.48 s. There are some small UX problems with basic HTML Facebook that I would recommend they improve on (placement of links/buttons, omnipresent header), but overall it is a much better experience for me since I feel much more in control. Same with basic HTML Gmail vs full Gmail. My point is that it is absolutely possible to not give in to shitty bloated web trends driven by the expectation to increase popularity, while making a quality, profitable website.
      - semi-extrinsic 10y ago
        > mbasic.facebook.com Mind blown. It even has messaging that works without having to install privacy-invading Messenger. You have just improved my facebook UX by a country mile.
        Nexxxeh 10y ago
        The combination of mbasic for Messenger, and m for normal Facebook browsing, is fine on Android. I don't install the awful FB apps on my phone any more, and I'm a fairly heavy Facebook user.
      - rtpg 10y ago
        mbasic.facebook.com is nice for when you want to save the bandwidth, but the experience is nowhere near as nice as the main website. It only loads the first 2 stories or so, requiring you to click forward many times. It also downscales all the media down, making it hard to appreciate a lot of things. The main facebook site makes a lot of media requests to preload the things you're going to start reading immediately. the main facebook site doesn't attempt to scale to the connection speed, which is unfortunate, but it offers a much better experience for those who have the bandwidth to pull in the pictures. Especially for the primary use case (scroll a bunch to see a bunch of people's stuff)
        vortico 10y ago
        I can see 8 stories on each page on mine, but I agree the images are smaller than I'd like. You have to click the image to get to the image page and then click "View Full Size" to see the full image. But with vimperator, it's much faster to get to that point than it sounds. On the other hand, simply clicking on videos delivers the full raw video, no slow Facebook video player/wrapper needed. I wouldn't want Facebook to scale things to my bandwidth. That gives me less control over what I see because the system is making mostly arbitrary decisions for me.
- ioquatix 10y ago
  I fought so hard for this at one of my current customers. But, no, we have Mbyte+ image maps for our pricing plan selection pages.
tribby 10y ago
>while it's probably not reasonable to optimize for them it's not an optimization, it's a best practice on the web. server side render and use javascript for progressive enhancement.
- BuuQu9hu 10y ago
  The web has moved on from progressive enhancement. Current practise is client-side HTML rendering.
  - zacmps 10y ago
    Unfortunately.
    - chalupa-man 10y ago
      I find it really fortunate. SPAs can use much much less data for the same content, which is a big plus when you're on a data-limited connection, as most users in the developing world are. If you spend much time on a site they also demand less CPU and thus less battery life (vdom updates are less intense than new page renders), which helps when you're on a mobile connection, and they feel much more responsive when you're on a high-latency connection, which you are again if you're in the developing world or on mobile. Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.
      - Gracana 10y ago
        That's fine for SPAs, what sucks is how many other sites are built that way. :/
      - minitech 10y ago
        > Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall. If and only if you do the SPA right. Compare Twitter (slow to load, slow to interact with, battery-draining, issues with maintaining scroll position, and all of these get worse the farther you scroll down) to the SPA version of https://mobile.twitter.com/ https://mobile.twitter.com/ (fast to load and interact with) to the static version of Mobile Twitter (even faster, no infinite scroll, works on Dillo).
superflyguy 10y ago
To be fair, the market is considered occasionally but a for-profit site isn't going to go out of its way to cater for those people with little money.
masklinn 10y ago
Low bandwidth is but one component, the other two are delay and packet loss. I spent the holidays at my parents's, they're hooked to 1024kbps ADSL[0], so theoretical 128kB/s. Effectively it hovers between 80k and 120k which is fine…-ish: the connection will regularly jump to ~7% packet loss and 2000±1000ms ping. Downloading at 80k is one thing, downloading at 80k with 3s round-trip and 1 packet in 15 missing things get much trickier, especially when most pages have a really high number of resources. [0] and nothing better is currently available short of cellular (they do get ok 4G, at least when the weather doesn't screw with it), though they're supposed to get fibre a year or two down the line

adrianN 10y ago

If you optimize for people on low bandwidth connections, you automatically also optimize for those with limited mobile data. And as a bonus, your website becomes faster for everybody with a fat pipe too.

vortico 10y ago
"Optimize" is somewhat the wrong word. "Straying from temptation" would be more accurate, since all garbage on webpages is placed there by a website manager's overzealous want to increase popularity or profit.
- rtpg 10y ago
  I understand some people don't use things like cloud software, but the internet isn't just blogs and newspaper websites. Sometimes styling is added to make web app UX better. Sometimes Javascript is used so that, even if the first load takes more time, subsequent actions will use less bandwidth. Sometimes more stuff is put on the page because 95% of users want that information to also show up. This is obvious and pedantic, but also counters half of the comments on these sorts of these stories
  - vortico 10y ago
    My point especially applies to web apps. I just loaded facebook.com, and it took 228 requests, 8,825 KB, and 17.0 s. Scrolling through the page is laggy while a stressful amount of muted videos start playing and mouse-hover events start firing. Compare this with mbasic.facebook.com, which is 22 requests, 107 KB, and 1.48 s. There are some small UX problems with basic HTML Facebook that I would recommend they improve on (placement of links/buttons, omnipresent header), but overall it is a much better experience for me since I feel much more in control. Same with basic HTML Gmail vs full Gmail. My point is that it is absolutely possible to not give in to shitty bloated web trends driven by the expectation to increase popularity, while making a quality, profitable website.
    - semi-extrinsic 10y ago
      > mbasic.facebook.com Mind blown. It even has messaging that works without having to install privacy-invading Messenger. You have just improved my facebook UX by a country mile.
      - Nexxxeh 10y ago
        The combination of mbasic for Messenger, and m for normal Facebook browsing, is fine on Android. I don't install the awful FB apps on my phone any more, and I'm a fairly heavy Facebook user.
    - rtpg 10y ago
      mbasic.facebook.com is nice for when you want to save the bandwidth, but the experience is nowhere near as nice as the main website. It only loads the first 2 stories or so, requiring you to click forward many times. It also downscales all the media down, making it hard to appreciate a lot of things. The main facebook site makes a lot of media requests to preload the things you're going to start reading immediately. the main facebook site doesn't attempt to scale to the connection speed, which is unfortunate, but it offers a much better experience for those who have the bandwidth to pull in the pictures. Especially for the primary use case (scroll a bunch to see a bunch of people's stuff)
      - vortico 10y ago
        I can see 8 stories on each page on mine, but I agree the images are smaller than I'd like. You have to click the image to get to the image page and then click "View Full Size" to see the full image. But with vimperator, it's much faster to get to that point than it sounds. On the other hand, simply clicking on videos delivers the full raw video, no slow Facebook video player/wrapper needed. I wouldn't want Facebook to scale things to my bandwidth. That gives me less control over what I see because the system is making mostly arbitrary decisions for me.
ioquatix 10y ago
I fought so hard for this at one of my current customers. But, no, we have Mbyte+ image maps for our pricing plan selection pages.

tribby 10y ago

>while it's probably not reasonable to optimize for them it's not an optimization, it's a best practice on the web. server side render and use javascript for progressive enhancement.

BuuQu9hu 10y ago
The web has moved on from progressive enhancement. Current practise is client-side HTML rendering.
- zacmps 10y ago
  Unfortunately.
  - chalupa-man 10y ago
    I find it really fortunate. SPAs can use much much less data for the same content, which is a big plus when you're on a data-limited connection, as most users in the developing world are. If you spend much time on a site they also demand less CPU and thus less battery life (vdom updates are less intense than new page renders), which helps when you're on a mobile connection, and they feel much more responsive when you're on a high-latency connection, which you are again if you're in the developing world or on mobile. Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.
    - Gracana 10y ago
      That's fine for SPAs, what sucks is how many other sites are built that way. :/
    - minitech 10y ago
      > Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall. If and only if you do the SPA right. Compare Twitter (slow to load, slow to interact with, battery-draining, issues with maintaining scroll position, and all of these get worse the farther you scroll down) to the SPA version of https://mobile.twitter.com/ https://mobile.twitter.com/ (fast to load and interact with) to the static version of Mobile Twitter (even faster, no infinite scroll, works on Dillo).

superflyguy 10y ago

To be fair, the market is considered occasionally but a for-profit site isn't going to go out of its way to cater for those people with little money.

masklinn 10y ago

Low bandwidth is but one component, the other two are delay and packet loss. I spent the holidays at my parents's, they're hooked to 1024kbps ADSL[0], so theoretical 128kB/s. Effectively it hovers between 80k and 120k which is fine…-ish: the connection will regularly jump to ~7% packet loss and 2000±1000ms ping. Downloading at 80k is one thing, downloading at 80k with 3s round-trip and 1 packet in 15 missing things get much trickier, especially when most pages have a really high number of resources. [0] and nothing better is currently available short of cellular (they do get ok 4G, at least when the weather doesn't screw with it), though they're supposed to get fibre a year or two down the line