One of the main reasons people are reluctant to use mobile internet on a regular basis is said to be the cost of data over CSD,GPRS,EDGE, UMTS etc. Not necessarily because data traffic is expensive, but rather because people are not sure of the cost due to the carriers complex price models. The European Union has, by the EU Roaming Regulation , made an effort to reduce roaming charges. However, this regulation does not include roaming charges on data traffic. This means that it is up to the mobile operators to charge as they like for data traffic. In some counties the data traffic can be as high as 12 Euro pr megabyte. [edit: just found an article from Times Online] Fortunately some carriers have seen this problem as well.
So, the least we can do as developers is to keep the data traffic to a minimum.Here are some basic tips.
General
The list here is long, spanning from naming conventions of cookies, css classes, cookie content, length of urls etc. I have picked two rather annoying things here:
The general tips is to make an effort to keep your markup clean and efficient. As pretty as indentation may look, it adds to the data cost. So do unnecessary line breaks in the markup. Line breaks and spaces are typically a problem in JSP programming. For Tomcat, a simple trick is to add these lines in your web.xml:
<init-param>
<param-name>trimSpaces</param-name>
<param-value>true</param-value>
</init-param>
Further, inline- styles and style sheets can be put into a separate file and implemented by the tag. This allows the style sheet to be cached more efficiently.
Compressing the response
On desktop web sites it is common to zip the response to the browser. I have noticed that this feature is becoming more common for mobiles as well. This can reduce the amount of data transferred significantly!
To illustrate the gain by compressing output I have made a simple test. I have compared the amount of data produced by this page ; compressed and not compressed. The test shows that a zipped page only produces 34% of data compared to the not compressed version. This means huge savings in terms of money. Read more about the test here. Compressed response is fairy easy to implement, and the options are many. I'll explain two options here. First, To determine if the device supports compressed responses just check for the http-header "accept-encoding" with the value "deflate,gzip".
1. php
The php solution is extremely easy to implement. There are at least two options in php. The first is to add ob_start("ob_gzhandler"); in the beginning of the php file. This callback function will automatically determine whether the device supports compressed content and send compressed or not compressed accordingly. The second is to add these lines in the php.ini file and has the same effect as the above:
php_flag zlib.output_compression on
php_value zlib.output_compression_level 2
2. apache module.
The apache web server is widely used and simple to configure. The mod_deflate module compresses content similarly as the above option. To enable this module you have to edit the apache config and/or the .htaccessfile. I have not tested this on a representative sample of devices but there are some known issues. Compressing style sheets for example, will not work on some devices. Another thing that is open for discussion is the user experience. Is a compressed page perceived as faster than a none-compressed page? How long time does the device use to unzip and render the markup?
Caching in the device
Implementing client side caching in a rational way improves the user experience and reduces the data transfer between the server and the device. Historically there has been issues regarding caching but these problems are mostly solved so my recommendation is to implement caching on pages that are relatively static. Here are some tips:
Using meta tags:
If you can, avoid using tags, use the http-header in stead (below). However, if there is no other way a sensible meta tag looks like this:
<meta http-equiv="expires" content="Mon, 20 Aug 2007 11:12:01 GMT"/>
<meta http-equiv="Cache-Control" content="max-age=3600"/>
This means, in theory, that the browser will not get the page again until the page has expired either by the max age or the the date set.
Using http-headers:
A more efficient and, in my experience a safer way, is to use the http headers (which also generates less markup). In php it may look like this:
header('Cache-Control: maxage=3600');
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
Just remember to put these statements at the top of your php script before outputting anything else.
The apache way:
The mod_expires is also fit for use here. When enabling this module Apache will write the appropriate http headers. Just add these lines in your Apache config file or .htaccess file:
ExpiresActive On
ExpiresByType image/gif A3600
ExpiresByType image/jpeg A3600
ExpiresByType image/png A3600
ExpiresByType text/css A2592000
These statements tells Apache to cache images and style sheets.
AJAX and javascript/ecmascript
In this context, the beauty of ajax is that ajax gives us the possibility to update just a section of a page without having to reload the full page with images, style sheets and markup. Using javascript or ecmascript also enables client side processing. This will relieve the web server of doing simple calculations, and of course prevent unnecessary data traffic.
Jason Delport has made an ajax example page for mobiles. This illustrates the huge opportunities ajax gives in terms of dynamic sites. The support for ajax is for the time being limited, but I believe this is a temporary issue. There are no easy way to determine ajax support programmatic. WURFL does not contain any information about ajax nor does ua-prof. The practical option is to check the http-header for content types javascript, x-javascript, ecmascript or similar.
Hope this helps! 🙂
