war stories webapps

Mobile phone networks can break your website

Sometimes my day job throws up some weird problems. Recently during development of a web app iPhones suddenly stopped loading the JavaScript file. No matter how far we rolled back the code it would not load. Other phones were fine and it had worked on the iPhone in the past. Eventually we found that the problem, of all things, was the mobile network! We only found this out because the JavaScript worked on Wi-fi but not on 3G and all the iPhones we tried were on the same carrier (I won’t say which but it begins with an ‘O’ and ends with a ‘2’). Certain carriers “optimise” web pages before sending them to phones as I found in this blog post. This is supposed to speed up sites on phones but can actually slow them down by introducing latency. We worked around this by putting the JavaScript in line. Luckily the mobile network I personally use doesn’t seem to do this (hint: it’s name is a single digit more than 2 and less than 4, 5 is right out). Next time your contract is up be careful which network you choose!
Fortunately, PubCrawler doesn’t seem to suffer from the issue.
A good way to test and validate a web app post carrier fiddling is to tether a handset to a computer. Then using Firefox with the User Agent Switcher add-on mimic the desired mobile phone. Viewing source will display just how much the mark-up, CSS and JavaScript has been altered. Images are usually transcoded (unless the Cache-Control response header is set to “no-transform”) and linked CSS can sometimes be brought in-line for example.
I think this issue highlights the complexity that mobile developers face when trying to troubleshoot a problem. Dealing with differences between handsets and software is the norm but add carriers to the mix and it makes things even harder.