Sunday, October 23, 2011

Why is social media on my one year old smartphone slow?

The short answer is the the developers have a trade off to make - browser bottleneck / network bottleneck.


Client side / Server side - Turning back the clock 10 years:

I write this to create context. Trying to be brief.

10 years ago there were no smartphones really, and very little in the way of mobile internet.

The database lived on a server in the computer room, your desktop intranet web pages interacted with the database via server side code (JSP, PHP, ASP, whatever)

The desktop machine itself did not have to be very powerful as JSP, PHP, ASP did all the hard work in the computer room.

The phrase "Server Side round trip" was born, to give a catchy phrase to what some folks described as a network bottleneck.


Mobile net & Smartphones - ½ of Server Side now replaced by Javascript:

Sun/Oracle and Intel sell less servers because of this. Cue displeasure.

Client side development using Ajax and jQuery is popular in some startups.

The downside for the mobile user, is that the network bottleneck has now been replaced by a browser bottleneck - javascript processing.

In 2011, the biggest browser announcements, were all about the speed of the javascript processing engine.

In 2012 the push for dual core smartphones is mostly going to be driven by single core, becoming sluggish under the weight of client side javascript.

Phrases like "Sluggish page loading" and "smartphone lockup" are just two of the new phrases emerging from this shift.


Is a browser bottleneck better than a network bottleneck?

For desktops in the workplace, a network bottleneck is unlikely to be an issue, so server side processing makes perfect sense.

For tablets, smartphones, access via 3G/4G dongles, it all depends on the country in which you live, and the amount of time you spend on the move.

I use a tablet and 90% of my browsing is done via home / work fast WiFi - no network bottleneck. Heavy Ajax and jQuery is probably using up battery life unnecessarily.

I live outside of the metropolitan areas in India, and my smartphone connection regularly varies between 2 bars and the maximum 5 bars.
Heavy Ajax and jQuery client side processing is the answer.
Your battery takes the hit, but you are able to work very effectively with less reliance on the network.

Giving just two examples does not really cover it, but I hope that is enough to stimulate your own research.


Big social media - where is my bottleneck?

Twitter and Google+ place least reliance on the network, and prefer to put a good portion of the database access and scroller code on the client side.

Seem strange to me to be naming Google there, as Google does have pretty unlimited server side resources.

Identica and Facebook place more reliance on the network, but are less taxing on your smartphone processor.

Server side scripting such as Php takes a lot of the strain in Identica and Facebook, meaning you are borrowing less of your phone out, when browsing their social media.

In short the Facebook datacentre is humming when you browse, rather than your smartphone processor being fully taxed.

Just to clarify, I am by no means a Facebook fan, however this an article about choice of technologies, which does not require me to like Facebook or Google+ or both.

Big Social Media is very expensive, and if the company can borrow half of your smartphone processor, rather than compute on the server side, then there is a financial incentive there, to use your electricity rather than their own wherever possible.


How can I see this for myself? I want to experiment:

Browse around on Twitter and Identica and notice the speed and strain on your browser. Are they different? Does one seem more responsive than the other?

By Twitter and Identica, I mean searching or logging in to the www.twitter.com or www.identi.ca urls, rather than using a dedicated smartphone app.

The dedicated smartphone app for Twitter avoids Ajax and jQuery and suchlike, and is optimised for the best native device language, and API access available.

No comments: