[waterhouse23]

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]

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]

"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]

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]

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]

> 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]

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]

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]

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]

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.

[masklinn]

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

[tribby]

>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]

The web has moved on from progressive enhancement. Current practise is client-side HTML rendering.

[scaryclam]

No, no it hasn't. Just because there are a bunch of terrible front end developers trying to push that notion doesn't make it true. Any half way competant front end developer will be able to create sophisticated websites that are usable for the vast majority of their users and they'll be using something like progressive enhancement to do it.

[tracker1]

Client rendering doesn't have to be so bad... I actually did do it as an optimization back in the dialup days. React is pretty nice, and if you really want to reduce payload, you can build against inferno or preact for similar results at a smaller payload, but since React packaged JS is usually less than a single moderately sized image, it's really less of an issue.

Although that doesn't mean to go ahead and throw in lodash + underscore + ramda + jquery + jquery extensions all on top of react/redux. Just because you're using a modern framework, doesn't mean it needs to be huge. You can build a basic app with preact and min+gz hitting a total size around 20-30kb.

Yes, that's more than server-rendered simple AMP-style html... on the flip side, you don't have to round trip for every screen either. It's also a LOT smaller than some of the behemoths out there, and even then, a lot of the time Images are the biggest hit in bandwidth.

[robin_reala]

That’s really not true for the majority of sites, in particular nearly every document site. There’s no one blanket fits-all best practise, but in general using a SPA is hurting a significant majority of users.

[zacmps]

Unfortunately.

[chalupa-man]

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.

[minitech]

> 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/ (fast to load and interact with) to the static version of Mobile Twitter (even faster, no infinite scroll, works on Dillo).

[Gracana]

That's fine for SPAs, what sucks is how many other sites are built that way. :/

[superflyguy]

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.