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

181–190 of 406 posts

Re: Engineering for Slow Internet

#181

Post by chiefalchemist »

FridgeSeal wrote: post #143
chiefalchemist wrote: post #142

Earlier quoted context omitted.

It's not always the application itself per se. It's the various / numerour marketing, analytics or (sometimes) ad-serving scripts. These third party vendors aren't often performance minded. They could be. They should be.

And the insistence on pushing everything into JS instead of just serving the content. So you’ve got to wait for the skeleton to dl, then the JS, which’ll take its sweet time, just to then(usually blindly) make half a dozen _more_requests back out, to grab JSON, which it’ll then convert into html and eventually show you. Eventually.

Yup. There's definitely too much unnecessary complexity in tech and too much over-design in presentation. Applications, I understand. Interactions and experience can get complicated and nuanced. But serving plain ol' content? To a small screen? Why has that been made into rocket science?

Re: Engineering for Slow Internet

#182

Post by iforgotpassword »

LorenzoGood wrote: post #165
iforgotpassword wrote: post #103

Earlier quoted context omitted.

Tried multiple VPNs in China and finally rolled my own obfuscation layer for Wireshark. A quick search revealed there are multiple similar projects on GitHub, but I guess the problem is once they get some visibility, they don't work that well anymore. I'm still getting between 1 and 10mbit/s (mostly depending on time of day) and pretty much no connectivity issues.

Wireguard?

Haha yes, thanks. I used Wireshark extensively the past days to debug a weird http/2 issue so I guess that messed me up a bit ;)

Re: Engineering for Slow Internet

#183

Post by meindnoch »

walterbell wrote: post #57

IETF draft proposal to extend HTTP for efficient state synchronization, which could improve UX on slow networks, https://news.ycombinator.com/item?id=40480016 The Braid Protocol allows multiple synchronization algorithms to interoperate over a common network protocol, which any synchronizer's network messages can be translated into.. The current Braid specification extends HTTP with two dimensions of synchronization:…

Yes, please! Even more layers of needlessly complex crap will definitely improve things!

Re: Engineering for Slow Internet

#184

Post by meindnoch »

amelius wrote: post #174

I have a question about this. I have multiple instances of curl running in different terminals, all using a single slow internet connection. How can I give priority to one of these instances?

Create multiple virtual interfaces, apply different traffic shaping to them, and then use the --interface option of cURL.

Re: Engineering for Slow Internet

#185

Post by pnt12 »

klabb3 wrote: post #166
walterbell wrote: post #57

IETF draft proposal to extend HTTP for efficient state synchronization, which could improve UX on slow networks, https://news.ycombinator.com/item?id=40480016 The Braid Protocol allows multiple synchronization algorithms to interoperate over a common network protocol, which any synchronizer's network messages can be translated into.. The current Braid specification extends HTTP with two dimensions of synchronization:…

Grump take: More complex technology will not fix a business-social problem. In fact, you have to go out of your way to make things this shitty. It’s not hard to build things with few round trips and less bloat, it’s much easier. The bloat is there for completely different reasons. Sometimes the bloat is unnoticeable on juicy machines and fast internet close to the DC. You can simulate that easily, but it requires the…

> Generally, ad-tech and friends cares very little about small cohorts of users.

Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win.

As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.

Re: Engineering for Slow Internet

#186

Post by nashashmi »

It takes a “special” skill Level to develop web applications in JS for low bandwidth connections. it takes time because frameworks and libraries are not built for this. there are very few libraries and frameworks in JS that are optimized for Low bandwidth connections. this requires having to program applications from scratch.

I went through such a process. Took me two weeks versus two hours using JS query

Re: Engineering for Slow Internet

#187

Post by tecleandor »

djtango wrote: post #64
future10se wrote: post #19

Earlier quoted context omitted.

Those I recognize (from interface, branding, strings, etc.): * Slack -- https://brr.fyi/media/engineering-for-slow-internet/load-err... * Signal (main screen) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * 1Password (config/about page) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * Zoom (updater screen on Mac) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d.…

Yes - name and shame. Slack is INFURIATING on intermittent connectivity. That is simply not good enough for a product who's primary value is communication. Anyone who has tried to use Slack: - in the countryside with patchy connection - abroad - in China - on the London Underground Can attest to how poor and buggy Slack is on bad internet. These aren't weird edgecases - London is a major tech hub. Remote workers and…

Slack and the Jira suite are terrible.

Slack web downloads 40MB of Javascript. The macOS Slack client, that I guess should have all that stuff already, downloads 10MB of stuff just by starting it (and going directly to a private text only chat).

Re: Engineering for Slow Internet

#188

Post by zerkten »

rpastuszak wrote: post #171
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 lived in Shoreditch for 7 years and most of my flats had almost 3G internet speeds. The last one had windows that incidentally acted like a faraday cage. I always test my projects with throttled bandwidth, largely because (just like with a11y) following good practices results in better UX for all users, not just those with poor connectivity. Edit: Another often missed opportunity is building SPAs as offline-first.

>> Another often missed opportunity is building SPAs as offline-first.

You are going to get so many blank stares at many shops building web apps when suggesting things like this. This kind of consideration doesn't even enter into the minds of many developers in 2024. Few of the available resources in 2024 address it that well for developers coming up in the industry.

Back in the early-2000s, I recall these kinds of things being an active discussion point even with work placement students. Now that focus seems to have shifted to developer experience with less consideration on the user. Should developer experience ever weigh higher than user experience?

Re: Engineering for Slow Internet

#189

Post by joseda-hg »

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 live in a well connected city, but my work only pays for other continent based Virtual Machines so most of my projects end up "fast" but latency bound, it's been an interesting exercise of minimizing pointless roundtrips in a technology that expects you to use them for everyting

Re: Engineering for Slow Internet

#190

Post by Lex-2008 »

jiggawatts wrote: post #157
RGamma wrote: post #139

Earlier quoted context omitted.

Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...

The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image i…

> "server side rendering" with a GPU instead of sending more JavaScript

Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources.

For many popular websites, png screenshot of a page indeed was several times less than webpage itself!

Post reply on HN