Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The web sucks if you have a slow connection

danluu.com

Post reply on HN
Print view View original

501–510 of 622 posts

Re: The web sucks if you have a slow connection

#501

Post by TeMPOraL »

StavrosK wrote: post #470
curun1r wrote: post #264

Earlier quoted context omitted.

This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experi…

Here in Greece, the internet is plenty fast (in bandwidth), but everything is far away, so there's lots of latency in opening every page. Going to the US on a trip, it's striking how much faster every website loads, there's no 300ms pause at the start anywhere. Because I got frustrated at fat websites downloading megabytes of useless things, I decided to start an informational site about this very thing: http://www.l…

Thanks for the links to lightweight CSS and JS libs; I actually need exactly that right now for a project.

Gitlab link is 500-ing, unfortunately.

Re: The web sucks if you have a slow connection

#502

Post by etatoby »

samuell wrote: post #387
ikeboy wrote: 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…

GMail has a HTML-only version that is much more lightweight and usable on slow / flaky connections.

It's worth it to memorize or bookmark the address, in case you ever need it:

http://mail.google.com/mail/h/

(on mobile browsers you need to "request desktop version" and then paste the address again, before you can see it)

Re: The web sucks if you have a slow connection

#503

Post by TeMPOraL »

rev_bird wrote: post #415
curun1r wrote: post #264

Earlier quoted context omitted.

This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experi…

>If browsers could expose the available bandwidth I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data. That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "reque…

Indeed; as an user, I don't want the site to decide what quality to serve me based on probing my device. It'll only lead to the usual abuse. I want to specify I want a "lightweight" version or "full experience" version, and have the page deliver an appropriate one on demand.

Re: The web sucks if you have a slow connection

#504

Post by hefty »

milesrout wrote: post #484
hefty wrote: post #471

Earlier quoted context omitted.

You could install the YouTube Plus browser extension and check "disable DASH playback" in the settings. Then if you start playing a video for a second or two and pause it, it will buffer the entire thing. The only downside is I think it reduces the maximum video quality for all videos to 720p.

I have a 1920x1200 monitor, so yeah I don't think so lol.

So do I and it's what I do. I can't really see much difference between 720p and 1080p on YouTube.

Re: The web sucks if you have a slow connection

#505

Post by fegul »

lmm wrote: post #487
samuell wrote: post #387

Earlier quoted context omitted.

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…

> I have a hard time understanding why this issue is not paid more attention. Ethiopia alone has some 99 million inhabitants, with smart phone usage growing by the hour. Some sources say "the country could have some 103 million mobile subscribers by 2020, as well as 56 million internet subscribers" [1]. How much disposable income will they have though? Most web products like those you describe are produced by busines…

You may be surprised. Certainly the number of people with disposable income will be less than in many other places but those that have disposable income often pay more.

Tax on cars is upward of 200% and traffic is becoming a major issue. When it comes to services, another major challenge is that there are no widely accepted payment mechanisms besides cash and checks. Debit cards only work with ATMs and some very select retailers.

Re: The web sucks if you have a slow connection

#506

Post by gkya »

gabemart wrote: post #158

Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of users on fast/uncapped connections, but that user agents on slow/capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc. Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them…

> Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them in the first place", but this is i) unrealistic, and ii) ignores the fact that while the typical HN user may like sparsely designed, text-orientated pages with few images, this is not at all true of users in different demographics. And in those demos, it's often not acceptable to degrade the experience of users on fast connections to accommodate users on slow connections.

This is prejudice. People use Craigslist, for example. If the thing is useful, people will use it. If there's a product being sold, and if it's useful to the potential clientele, they'll buy it. Without regard to the UI.

In the past ten years while my connection speed increased, the speed at which I can browse decreased. As my bandwidth increased, all the major websites madly inflated.

> So -- if I write a web page, and I want to include a large asset, but I want to indicate to user agents on slow/capped connections that they don't _need_ to download it, what approach should I take?

Put a link to it with (optionally) a thumbnail.

Re: The web sucks if you have a slow connection

#507

Post by aczerepinski »

gabemart wrote: post #158

Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of users on fast/uncapped connections, but that user agents on slow/capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc. Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them…

I think srcsets are a reasonably proxy for this. Serve extremely optimized images to mobile devices, and the full images to desktops.

It isn't perfect - you'll get some mobile devices on wifi that could have consumed the hero images and some desktop devices still on dial up, but it's still a lot better than doing nothing.

Re: The web sucks if you have a slow connection

#508

Post by Asooka »

rev_bird wrote: post #415
curun1r wrote: post #264

Earlier quoted context omitted.

This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experi…

>If browsers could expose the available bandwidth I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data. That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "reque…

Progressive resources would help a lot here. We have progressive JPEGs and (I might be wrong) PNGs, you can set your UA to low-fi mode and it will only download the first layer of the JPEG.

Re: The web sucks if you have a slow connection

#510

Post by etatoby »

I design and write my company's framework, that other devs use to write websites and webapps.

I base my work on existing technologies (lately Laravel, which means Symfony, Gulp, and hundreds of other great libraries) but I always strive to:

1. Reduce the number of requests per page, ideally down to 1 combined and compressed CSS, 1 JS that contains all dependencies, 1 custom font with all the icons. Everything except HTML and AJAX should be cacheable forever and use versioned file naming.

2. Make the JS as optional as possible. I will go out of my way to make interface elements work with CSS only (including the button to slide the mobile menu, various kinds of tooltips, form widget styling, and so on.) Whenever something needs JS to work (such as picture cropping or JS popups) I'll make sure the website is usable and pretty, maybe with reduced functionality or a higher number of page loads, even if the JS fails to load or is turned off. Also, the single JS file should be loaded at the end of the body.

2b. As a corollary, the website should be usable and look good both when JS is turned off, and when it's turned on but still being loaded. This can be achieved with careful use of inline styles, short inline scripts, noscript tags, and so on.

3. Make the CSS dependency somewhat optional too. As a basic rule, the site should work in w3m, as pointed out above. Sections of HTML that make sense only when positioned by CSS should be placed at the end of the body.

I consider all of this common sense, but unfortunately not all devs seem to have the knowledge, skill, and/or time allowance to care for these things, because admittedly they only matter for < 1% of most website's viewers.

Post reply on HN