RSS Feeds

A good web application spoilt by poor Internet performance

My wife and I have a cottage on the Greek island of Alonissos – at the very top of the village in the photo to the right.  We like the remoteness, food, walking, swimming, our terrace with a fantastic view over Aegean and the life-style in general.  Internet connectivity isn’t a high priority when I am on the island, so I haven’t gone through all the hassle of getting an ADSL line; I just buy a drink or two at one of the local tavernas and use its WiFi when I need Internet access.  This works fine for all the access that I need: managing the websites that I look after, Skype, access to my various bank / credit cards services, YouTube, etc. – with one annoying exception: I need to transfer money routinely from my UK Sterling bank account to my Greek Euro one to cover living expenses.

I use MoneyCorp GPS to do this.  MoneyCorp is a market leader in this Forex sector that offers competitive rates and seems to be widely recommended (e.g. by the Telegraph).  The GPS application provides all functionality that I need except that it is unusable on these taverna connections: it hangs and times-out.  It seems to need a reasonable internet bandwidth to work robustly, and luckily for me there is an Internet service in the main port on the island which offers Enet connection and a reasonable Internet bandwidth, so this an inconvenience rather than a show-stopper. Even so, for an application implementing a money transfer service, I would expect it to provide a functional service 24x7 from pretty much anywhere in the world, given a reasonable minimum Internet service.

So following the theme of my last few articles on optimising web applications for network and browser performance, I decided to drill down into the GPS application to see just why it was the worst application that I had measured with Google Page Speed, scoring 36/100 (my next article will discuss a few more that I have subsequently found).  As far as I can see, the designers may have developed a good application in functional terms, but they seem to have ignored some basic rules for web optimisation:

Having browsed some of the other pages such as the Transfers and Payments functions, I see that javascript components seem to be randomly loaded from either WebResource.axd or ScriptResource.axd, with the latter being compressed, but not the former.  Bizarre.

So in previous articles I’ve discussed how to optimise your own web applications and packages such as phpBB.  Here we have an example of a corporate B2C application that is undermined by sloppy implementation details and ignoring some basic rules for good web performance:

I am not sure of the exact reasons for the time-out because I haven’t any access to the server-side logs, but the system is clearly struggling.  The secure HTTPS protocol is a must for this type of financial application, and this complicates some techniques for page optimisation.  Even so, GPS is sending out 223 – 595 KiB (depending on caching) over this HTTPS stream, when with a few tweaks it needs to send 15 KiB to render the home page, plus another 15 KiB or so asynchronously to initialise the ticker-tape.  This poor implementation means that the system traffic is perhaps 5-10x greater than it needs to be, and any poor performance is very much self inflicted.  All I hope is that MoneyCorp manage to fix this before the autumn, so that I can do my Forex transactions from my local taverna on my next visit to the island!


Post a comment

Please note that your name is required and that all posts will not be visible until authorised by an administrator.

  Required
  A valid mail address must be supplied
A cookie will store your name/url for three months
 Sorry, but you must answer this easy sum as a SPAM prevention measure.
 
 

You should be aware that all information on blog site is © Terry Ellison 2010 and made open access under the Creative Commons Artistic Licence.

Your comments will only publicly available after you have carried out email confirmation. Your email address will only used for this purpose and is not made public.

Comments that are not confirmed will be automatically deleted after 7 days.

The blog author reserves the right to delete comments which breach copyright or the rules of site etiquette as he determines (such as unnecessary use of obscenity or spam content).