Applications Optimized for Low Speed Connections

Constantly dealing with clients around the globe has taught us one thing: Internet connection speed is not the same everywhere. And differences are huge.

When building the last-generation web application with all kinds of bells and whistles, developer often implicitly assume that clients won't even bother having to download, let's say, one megabyte or more, during their first connection to the site. Often, even successive roundtrips to the server require the clients to sustain traffic in the order of magnitude of the megabyte. This is not a problem when clients enjoy bandwidths of several megabits per second. Unfortunately, such web applications dramatically impair the user experience of less fortunate users, up to the point of becoming unusable applications. There's no point in having an amazing application when your users cannot use it.

I haven't got for fresh statistics but if you want to make you an idea, with a quick Google search you come up with Net Index. Users from some African countries, for example, has an Internet connection well below 1 Mbps. Truth be told, those figures are pretty better than what I'm used to deal with: many clients of ours have bandwidth in the order of 10kbps. If you're old enough and lucky enough to have used a 14.4 kbps modem back in the 90's, imagine you're going to open some web page with such a connection. The result? An incredible pain: we're not used to waiting dozens of seconds while a page renders anymore.

Nowadays, the culprits aren't limited to the usual suspects: huge high-resolution images, multimedia content, documents, lack of HTTP compression, etc. Paradoxically, these problems are easier to solve, when you detect them, and the patch usually hasn't got a great (if any) on your application design.

Let's see some basic examples.

View State Information

Many web applications, especially those developed with enterprise technologies such as Java EE and Microsoft .NET, incur in an overhead that is necessary to maintain the information used by the framework itself: the dreaded view state information (the name may vary, depending on the specific technology jargon). A medium sized form can easily generate overheads of hundreds of kilobytes, and there's nothing easy you can do to reduce it without having to redesign your application.

XML/Web Services

Safe harbour statement: although some people may think otherwise, XML and Web Services are not synonyms. I mix and match them here only for simplicity's sake.

XML is widely used in web applications nowadays. Many development environments automatically generate artifacts that produce and consume XML without the developers having to explicitly handle it. Sometimes, a developer might not even be aware of it. Web Services clients and servers generated in modern Java EE and .NET IDEs both manifest this behaviour.

The problem is: the generated XML isn't optimized at all. And although it's true that client-server connections can be compressed (XML, being textual, deflates very well), this doesn't hold true when code is executed on the client (such as JavaScript).

Asynchronously Fetch Data

Some clients express the desire of having huge windows containing a wealth of information while other prefer smaller windows, easily reachable from one another. But "huge window" does not mean that every user is always going to use all the information. Windows that load asynchronously have a big advantage: instead of always downloading all the content, the page can be designed to load at startup only the strict minimum. Thus, the clients don't need to wait for all the page to be loaded and, depending on the window logic, they can even start and use it while data is still being fetched.

Carefully designed pages can be very responsive and load additional data only when triggered by some "event". Additional logic can be built into the page so that data is intelligently fetched from the server and appropriately filtered.

Caching Data

This may sound silly but we've seen so many under-optimized systems out there suffering from this problem that I think it deserves being mentioned. Many applications and all of their "resources" are just bundled altogether and deployed on an application server. Separating volatile content (non-cacheable data such as dynamically generated pages) from static content is a fundamental design decision, in such situations.

Instead of having the application server provide all the content to the clients (keeping precious threads busy), a properly configured web server caching data in front of the application server should be seriously taken into account.

What We're Offering to Clients with Slow Connections

Over the years we've learnt many lessons about dealing with seriously slow network connections. In fact, our applications are still being used by clients with deadly slow connections (in the few kbps range). Fine-tuning the network consumption of our applications is indeed part of their standard development life cycle.

But tuned doesn't mean stripped down. Just because we believe that the user experience is a fundamental value of an application, we're not trading it off easily. You don't have to give up a great user experience just because your connection is slow.
On the contrary, our software platform uses sophisticated solutions to provide the best user experience to our clients, both on fast and on slow internet connections, retaining the pleasant and intuitive design that sets our software apart from its competitors.

Try Our Money Transfer Software Now!

The best way to discover how our money transfer software can help your business is contacting with us. We'll be glad to answer all your questions and help you find the best solution to your needs.