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

Engineering for Slow Internet

brr.fyi

Post reply on HN
Print view View original

381–390 of 406 posts

Re: Engineering for Slow Internet

#381

Post by SlowBro »

SlowBro wrote: post #364

I've been looking into how to survive low bandwidth/high latency/frequent disconnecting internet, because we may need to save money at home and temporarily switch to an unlimited 2G speed (64kbit) cell data plan as our primary internet for a few months. (Red Pocket's $7/mo. 1GB GSMA plan paid annually.) Not only is Red Pocket notoriously bad at limiting both bandwidth and are horrible with latency, we also live far f…

I was reminded that Google Cloud offers a free forever 1GB RAM server with 1GB of network egress. In the US, additional egress costs $0.02/GB. A server sending 5KB/data every hour of every day for 30 days will cost you about 25 cents a month :-)

Re: Engineering for Slow Internet

#382

Post by bostik »

bobbob1921 wrote: post #259
nicoburns wrote: post #241

Earlier quoted context omitted.

> which is obviously weighed down by the libraries, but largely is as heavy or light as you make it One thing which surprised me at a recent job was that even what I consider to be a large bundle size (2MB) didn't have much of an effect on page load time. I was going to look into bundle splitting (because that included things like a charting library that was only used in a small subsection of the app). But in the end…

My experience agrees with this comment – I’m not sure why web browsers seem to frequently get hung up on only some Http requests at times, unrelated to the actual network conditions. Ie: in the browser the HTTP request is timing out or in a blocked state and hasn’t even reached the network layer when this occurs. (Not sure if I should be pointing the finger here at the browser or the underlying OS). However, when tes…

Chrome has a built-in, hard coded limit of six (6) concurrent requests. Once you have that many in flight, any subsequent requests will be kept in queue.

Now take a good, hard look at the number of individual resources your application's page includes. Every tracker, analytics crapware, etc. gets in that queue. So do all the requests they generate. And the software you wrote is even slower to load because marketing insisted that they must have their packages loading at the top of the page.

Welcome to hell.

Re: Engineering for Slow Internet

#383

Post by luuurker »

chipdart wrote: post #36
danpalmer wrote: post #9

Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…

> In Australia you're just 200ms from everything most of the time. (...) > The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast. The 200ms is telling. I bet that WhatsApp is one of the rare services you use which actually deployed servers to Aust…

Part of the problem seems to be the cost of peering in Australia:

https://blog.cloudflare.com/bandwidth-costs-around-the-world

Re: Engineering for Slow Internet

#385

Post by filleduchaos »

Aachen wrote: post #368
filleduchaos wrote: post #335

Earlier quoted context omitted.

The "html5 native way of doing things" is not necessarily inherently fast (or reliable) without scripting tbh.

I'm thinking of UI elements that are often half-implemented in JavaScript but also exist natively nowadays, such as sliders. What kind of thing are you thinking of?

If by slider you mean range slider, they only really work out-of-the-box for integer values.

If by slider you mean carousel, HTML/CSS-only carousels lack a full range of interactivity without...scripting

And both those things don't really have anything to do with application frameworks.

Re: Engineering for Slow Internet

#386

Post by collinmanderson »

matthews2 wrote: post #146
devjab wrote: post #85

Earlier quoted context omitted.

We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients like Tauri. You can also deploy very near people if you work “on the edge”. I’m not necessarily disagreeing with your overall point, but modern JS is actually rather good at dealing with slow internet for server-client “applications”. It’s not necessarily easy to…

HTTP/2 push is super dead: https://evertpot.com/http-2-push-is-dead/

Very sad. I use http/2 push on my website to push the CSS if there’s no same-origin referrer. It saves a full roundtrip which can be pretty significant on high latency connections. The html+css is less than 14kb so it can all be sent on the first roundtrip as it’s generally within TCP’s initial congestion window of about 10*1400.

The only other alternative is to send the CSS inline, but that doesn’t work as well for caching for future page loads.

103 Early Hints is not nearly as useful as it doesn’t actually save a round trip. It only works around long request processing time on the server. Also, most web frameworks will have a very hard time supporting early hints, because it doesn’t fit in the normal request->response cycle, so I doubt it’s going get much adoption.

Also it would be nice to be able to somehow push 30x redirects to avoid more round trips.

Re: Engineering for Slow Internet

#387

Post by malinens »

arp242 wrote: post #327
jiggawatts wrote: post #113

Earlier quoted context omitted.

By far the lightest weight JS framework isn't React, it's no javascript at all . I regularly talk to developers who aren't even aware that this is an option.

When used well, JS will improve the experience especially for high-latency low bandwidth users. Not doing full page refreshes for example, or not loading all data at once. So no, "no JS at all" is not "by far the lightest weight" in many cases. This is just uncritically repeating dogma. Even 5K to 20K of JS can significantly increase performance.

I always ask people to give example of real world SPAs where JS is "used well" and nobody could give me an example

Re: Engineering for Slow Internet

#388

Post by 2143 »

chipdart wrote: post #36
danpalmer wrote: post #9

Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…

> In Australia you're just 200ms from everything most of the time. (...) > The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast. The 200ms is telling. I bet that WhatsApp is one of the rare services you use which actually deployed servers to Aust…

I kinda chuckled that you left out most of Asia.

Most global companies (at least the US-based ones) have deployed in India, where I'm at right now. I suppose a billion people online is too big of a market to ignore (or not; I really don't know). Or there are services that I'm completely unaware of that's not in India.

Internet's pretty fast as well. Much faster than a certain conspicuous European country you'd expect to have fast internet ;)

Re: Engineering for Slow Internet

#389

Post by themoonisachees »

themoonisachees wrote: post #79
drozycki wrote: post #41

Earlier quoted context omitted.

I get 400 Mbps down standing at the door of that same diner. My understanding is that 4G bands are repurposed for 5G in rough proportion to the usage of 4G vs 5G devices at that tower, plus there’s some way to use a band for both. In any case I was having these indoor performance issues back in 2019. I’m pretty sure it’s an Intel issue, and any Qualcomm modem would be fine.

I see this in my french city, there's a particular spot on my commute where my phone (mediatek) will report 2 bars of 5G but speeds will actually be around 3G. I've also noticed other people on the tram having their videos buffer at that spot, so it's not just me. The carriers do not care, of course. I think there's just some of these areas where operational conditions make the towers break in some specific way.

It's very much not an overloading issue. This always happens, even at 3 AM.

Re: Engineering for Slow Internet

#390

Post by atoav »

lukan wrote: post #137
padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

"I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly." No need to invent time travel, just let them have a working retreat somewhere with only bad mobile connection for a few days.

My first education was in industrial design, there designers usually have pride in avoiding needless complexity and material waste.

Even if I do web services I try to do so with as little moving parts as needed and with huge reliance on trusted and standardized solutions. If see any addition of complexity as a cost that needs to be weighed against the benefits you hope it brings you will automatically end up with a lean and fast application.

Post reply on HN