Ask HN: Do you test your applications over low quality connections?

9 points by entuno ↗ HN
A lot of applications (both web and mobile) perform very poorly over low quality Internet connections, which can make them unusable over some mobile connections.

I'm curious how many people are testing their application performance and usability over these kinds of connections (low bandwidth, high latency or lots of packet drops), and the extent to which the results of that testing lead to changes in the applications.

And if you are doing this kind of testing, how do you do it? Simulating a poor network connection with something like the sch_netem module (https://openwrt.org/docs/guide-user/network/traffic-shaping/sch_netem), the built-in browser tools, actual low quality connections, or something else? Is this a regular part of your testing process, or a more ad-hoc thing?

6 comments

[ 4.0 ms ] story [ 22.8 ms ] thread
I’ll check with the built-in browser tools. But it’s hard to do anything about low-quality connections in particular at the application level. For example I pay attention to my overall page size (trying to keep it under 500kb), and to the server-side processing time (trying to keep it under 50ms). If I’ve done that, there’s very little additional work I can do to optimize for dropped packets, the protocol should handle that for me.
The UI should handle it gracefully, for example by deactivating buttons on first click and showing spinners where appropriate.

In one case I load required assets while someone starts filling a form so that the website is ready to generate a PDF when the form is filled. This gives it a minute to load, with fallbacks if it fails.

At Google we used to have a wifi network you could connect to that was intentionally low quality for just this.
along with it i like to test my web apps with low end devices. im talking about the cheapest androids you get out there.

regular users blw my mind, most people got tens of apps open simultaneously, more of those running as background services, even hundreds of tabs in their mobile browsers.

That's also a really good thing to be testing - both low performance and the lower resolution screens. There's a lot of old and cheap devices out there, and most developers will never use them.
I check it with the chrome dev tools. Normally there's a limit below which it makes little sense to keep optimizing (which depends on the app's intended target). When I hit that limit I stop bothering.