Live data from Hacker News

The web sucks if you have a slow connection

danluu.com

391–400 of 622 posts

Re: The web sucks if you have a slow connection

#391
post #185

Earlier quoted context omitted.

There is making the web more janky and hard to use and making it a simpler page. I think there is a balance here we can find.

I think AMP is that "bring back the 90s movement". No Javascript. Just super light and fast loading webpages like in the good ol' days. God I miss the late 90s and the internet. Even looking through neocities gives me a pang of nostalgia. Now everything has to be "Material Design" or "Flat". ¯\_(ツ)_/¯

Everyone thought it was silly when I did that for my site (minimal css, no js, static pages with hugo). But yea I agree, that's the right future for the web and design.

Re: The web sucks if you have a slow connection

#394
post #173

Earlier quoted context omitted.

Random idea: Get the current time in a JS block in the head, before you load any CSS and JS, and compare it to the time when the dom ready event fires. If there's no real difference, load hi-res backgrounds and so on. If there is a real time difference, don't.

Wouldn't that be measuring latency more so than bandwidth? You'd run the danger of confusing a satellite internet connection (high(ish) bandwidth, high latency) with a third-world, low bandwidth connection.

Satellite ISPs have low data caps and/or charge a lot per GB of transfer. Avoiding unnecessary downloads seems like the correct behavior in this case.

I think the best solution would be an optional http header. That way, the server could choose to send a different initial response to low-bandwidth users. If connection speed is solely available via JavaScript API or media query, then only subsequent assets can be adapted for users on slow connections.

Re: The web sucks if you have a slow connection

#396

Earlier quoted context omitted.

Hmm, either your experience, or memory, of the nineties / dial-up, is different than mine and all of my (quickly polled friends). We all built a library of painfully-obtained 320x200 horrible overcompressed video... ahh, the memories of RealPlayer. Some video was down to 180p... heck, I still have videos that were one or two megabytes in size in my archives - that I darn tootin' well waited hours to download :)

Please don't mention RealPlayer again. I feel ill and queasy thinking of that piece of software, its million rewrites and the CPU hog they released for Linux (at least on my lame hardware). I remember using "download accelerators" to try and grab files faster back in the day. Who knew they were just doing 4 simultaneous downloads of ranges of the same file eh? Ah I feel old

TIL the RealPlayer brand still exists... http://www.real.com

Re: The web sucks if you have a slow connection

#397
post #344

Earlier quoted context omitted.

Wow, uncanny resemblance to Giffen goods: https://en.wikipedia.org/wiki/Giffen_good

How so? I don't really see the similarity

Both describe unexpected effects when trying to extrapolate from price and quantity involved in individual use cases.

Jevons: Quantity required per use goes down, so you might expect total demand to decrease. Instead total consumption goes up.

Giffen: Price per use goes up, so you might expect total demand to decrease. Instead, total consumption goes up.

Either could increase consumption by displacing available substitutes, though that's not necessarily the case with Jevons. They are indeed different phenomena, they just have some similarities.

Re: The web sucks if you have a slow connection

#398

Earlier quoted context omitted.

Agreed. body{max-width:640px;margin:auto} The extra 33 bytes won't slow things down (unless you somehow hit the next ~1kb packet boundary) line-height 1.5; would also make it more readable.

640px would be a problem — that's approximately 15em on my screen. I don't think that unit is supposed to be about hardware pixels, but... Well, that's how it seems to be implemented anyway. Ems usually do better.

On hidpi screens they're emulated pixels, not hardware pixels (pretty much for this reason).

Re: The web sucks if you have a slow connection

#399

Earlier quoted context omitted.

Text articles are probably the most widespread type of content on the web. Most web sites are not web apps. But many developers want to re-construct web sites into web app architectures even when there's no benefit to the end user. I posted the links below on a previous discussion about AMP. They are two examples of basic, javascript-free web pages with text content. There's about 2500+ words on these test pages, but…

Version B could probably be optimized here by not loading two very similar fonts. You can also try loading the font locally first, to avoid the download if it's installed on the user's system. Finally, unicode-range lets you avoid the download completely if that character isn't included on the page. Not a likely outcome on an English page, but a good practice regardless. Webfonts are tough to optimize, but not imposs…

It could avoid loading the font entirely. Why does every webpage assume I want to use their fonts?

Re: The web sucks if you have a slow connection

#400
post #74

>When I was at Google, someone told me a story about a time that “they” completed a big optimization push only to find that measured page load times increased. When they dug into the data, they found that the reason load times had increased was that they got a lot more traffic from Africa after doing the optimizations. The team’s product went from being unusable for people with slow connections to usable, which cause…

I've tried using Google products from Africa (Ethiopia ... last time this January), and generally, it is right out unusable. JS-heavy apps like GMail will never load properly at all. This while the connection in itself is not THAT bad. I use to use a 3G/4G mobile connection and it generally works excellent, with pretty quick load times, for everything else than javascript-heavy web apps. I have a hard time understand…

It's not only about connection speed but also about infrastructure. If you look at this map https://cloud.google.com/about/locations/ you'll see that your packets have a looong way to reach their data center. AWS is no better than Google on this point. Guess it's not bankable
Post reply on HN