To Top

How to Speed Up Your Mobile Site

Along with the development of mobile Internet grows the need to optimize the time of the page load for mobile sites. Even the most advanced smartphones on Android, iOS, WebOS, BlackBerry OS, and others have a processor with a frequency of less than 1Ghz, and 3G speed can be considered as rather slow (the download speed is 3 times less than DSL).

Mobile devices have inherited the problems of “large” machines: starting with the number of http-requests and finishing with the effectiveness of JavaScript.

Features of mobile devices

Except that they can be easily placed in a pocket and it’s a lot easier to lose them, there are several key differences between mobile devices to desktops:

• low screen resolution;
• slow connection;
• limited cache size;
• a lot of different devices and form factors;
• low power of processors;
• broad support for HTML5;
• relatively new browsers (in this world no one knows about IE6).

General recommendations

Mobile sites have the majority of performance problems of the “large sites”, that’s why many of these techniques came from the desktop optimization:

• use gzip for the text data compression;
• put the CSS in the header of an HTML document, and JavaScript at the bottom of the page;
• combine the JavaScript and CSS files, which are used throughout the site. This will reduce the number of HTTP requests, which is very critical for mobile sites;
• use minimization and obfuscation for CSS and JavaScript code;
• it’s better to inline into the page JS and CSS that are used only one time on the site, as well as small JS and CSS (5 kB) and not to place it to the separate files;
• many mobile browsers (for example, Android or Opera Mobile) have a common limit on the number of connections, it is not more than 4-6. Using these browsers for a domain sharding can only be harmful for the time of the page load;
• at the same time Android browser supports the HTTP pipelining, which allows you to send to the server 3 requests in one connection at once. Do not forget to make sure that the server supports HTTP pipelining;
• it is very important to compress the files correctly (without any visible loss of quality). For example, you can use – more details about this;
• avoid or at least make redirects cacheable;
• for iOS use Quicktime Reference Movies, it allows you to “give back” to the visitor different video files, according to the capabilities of his Internet connection;
• benefit from WebSockets if it is possible (full support is now only in iOS Safari 4.2-4.3, partial in Opera Mobile 11.1).

HTML and CSS optimization

Broad support for HTML5 and CSS3 in mobile browsers allows you to use the latest technologies for sites’ optimization:

• HTML code should be extremely simple. Use the semantic elements in HTML5, specify , exclude optional xmlns attributes. Also try to reduce the number of divs and classes;
• Remove useless input, and if you use it, then use it in HTML5 formats; use gradients instead of CSS-backgrounds – it drastically reduces the number of trips to the server;
• CSS provides a lot of other things, the use of which is more effective than the use of images (shadows, rounded borders, multiple backgrounds, embedded svg and canvas).

Image Optimization

Along with the fighting against unnecessary roundtrips to the server, it is important to minimize the size of uploaded files. In this perspective, image optimization is the most important element:

• use CSS-sprites to optimize the logos and icons;
• in html and css encode an image in base64 – a very effective way, because it is supported by most mobile browsers, and the encoding occurs on the server side. In addition to PHP – base64_encode (), you can use the technology of the HTML5 Canvas – toDataURL ();
• use Unicode Emoji for coding icons instead of images (supported starting with iOS 2.2, as well as in many Japanese phones).

Mobile screens have a much lower resolution than the screens of desktop computers. CSS allows us to determine user’s current screen resolution, and depending on it to transfer the version of the image, which has a suitable resolution.
[code]/* Screens bigger than 480px */
@media only screen and (min-device-width: 481px) {
#header { background-image: url(header-full.png); }

The above code specifies that the user’s screen width more than 480px and instructs the browser to upload a picture header-full.png with full resolution. Here is the following code, determining that the screen width less than 480px, offers a browser image, adapted to the small screen:
[code]/* Screens smaller than 480px */
@media only screen and (max-device-width: 480px) {
#header { background-image: url(header-small.png); }

As a result of mutual understanding between the site and your browser the size of the loaded data on your mobile device drops significantly.

But first of all, you should take care of the user’s convenience. Using the same principle (separate content for mobile and desktop devices), can make the site enjoyable to watch for users with high-resolution screens, while not harming other visitors. For example, iPhone 4 users have used to that fact that on the screen of their phones should be images with a high DPI (eg 300). And if you don’t want your site look shabby on Retina screens, you will need to prepare another separate set of pictures in high resolution, and download them using CSS Media Queries.
[code]/* High dpi */ @media only screen and (min-resolution: 300dpi), only screen and (-webkit-min-device-pixel-ratio: 1.5), only screen and (min–moz-device-pixel-ratio: 1.5) { #header { background-image: url(header-300dpi.png); } } /* Low dpi */ @media only screen and (max-resolution: 299dpi), only screen and (-webkit-max-device-pixel-ratio: 1.5), only screen and (max–moz-device-pixel-ratio: 1.5) { #header { background-image: url(header-72dpi.png); } }[/code]

This is exactly the case when it is necessary to sacrifice performance in favor of the users’ convenience.

Optimization, depending on your connection speed

Starting with Android 2.2 Froyo developers have got the opportunity to receive information about the current type of Internet connection in the device. It is implemented with the object navigator.connection.

Here is an example of data from the device, which works in 3G networks:
[code]navigator = {
connection: {
"type": "4",
"UNKNOWN": "0",
"ETHERNET": "1",
"WIFI": "2",
"CELL_2G": "3",
"CELL_3G": "4"

The connection type “4”, which corresponds to CELL_3G. Using a simple script can determine the connection type, and pass this information as a CSS class in HTML element.
[code]// Initialize variables
var connection, connectionSpeed, htmlNode, htmlClass;

// Create a custom object fallback if navigator.connection isn’t available
connection = navigator.connection || {‘type’:’0′};

// Set connectionSpeed
switch(connection.type) {
case connection.CELL_3G:
// 3G
connectionSpeed = ‘mediumbandwidth’;
case connection.CELL_2G:
// 2G
connectionSpeed = ‘lowbandwidth’;
connectionSpeed = ‘highbandwidth’;

// set the connection speed on the html element, i.e. <html class="lowbandwidth">
htmlNode = document.body.parentNode;
htmlClass = htmlNode.getAttribute(‘class’) || ”;
htmlNode.setAttribute(‘class’, htmlClass + ‘ ‘ + connectionSpeed);[/code]

As a result, when determining the low-speed connection, we pass the visitor’s browser optimized images using CSS:
[code].highbandwidth .logo { background-image:url(‘logo-high.jpg’); }
.mediumbandwidth .logo { background-image:url(‘logo-medium.jpg’); }
.lowbandwidth .logo { background-image:url(‘logo-low.jpg’); }[/code]

Still, we should give users a right to choose. Therefore, it will be a good practice in addition to common options –
[code]version of the site desktop | mobile[/code]

-to give the choice of
[code]connection Speed: High | Medium | Low[/code]

Use simple rules – “if pixels are not visible, they should not be loaded”, but at the same time “you should not decide for the user, you can only recommend.”


If in most cases with the desktops the decision is in favor of an external file, then with mobiles is likely the opposite. Because of the small size of the cache we can’t talk about the big and long-term savings. There are a few tips to optimize the speed of reloading pages:

• cache the ajax;
• use far-future cache expiration headers;
• Avoid cookies, instead use localStorage (cookies are sent by http-requests and greatly increase the size of transferred data). LocalStorage and SessionStorage – these are HTML5 technologies, which are more effective alternative to cookies. There you can also store and external CSS and JavaScript.

An important limitation to LocalStorage and SessionStorage is that they can only store data of String type. Therefore, you should first transfer the data to string format and then restore the original with JSON.stringify () and JSON.parse ():
[code]var user = {
firstName: ‘Joe’,
lastName: ‘Schmoe’,
age: 40

// Store the object
localStorage.userInfo = JSON.stringify(user);

// Retrieve the object
var user = JSON.parse(localStorage.userInfo);[/code]

The sizes of data that can be stored in these facilities vary in different browsers, but 5 Mb should be enough for most of them. An interesting point is that devices on Android and BlackBerry OS are able to keep the cache even after the turning on / off the device, at the same time iPhone cannot boast with that.

Smartphones iPhone 4 Galaxy S Nexus S Blackberry Torch
OS / Ver iOS/4.3 Android 2.2 Android 2.3 Blackberry 6
Persistent* 0 4 4 25
Memory** 100 4 4 25

Tablets iPad 1 iPad 2 XOOM
OS / Ver iOS/4.3 iOS/4.3 Android 3.0
Persistent 0 0 20
Memory 20 50 20

* Persistent cache means after restarting the process or power-cycling the device.
** Memory cache also applies to locking the screen or using other apps, more information about the cache in mobile devices can be found in a blog of the Blaze company.

Javascript optimization

The low processor power in mobile devices makes urgent the problem of struggling for reducing the load. So Google’s research shows that parsing every 1 KB of JavaScript code is about 1 ms.

• Avoid javascript timeout animation, it is better to use CSS3 transitions instead (but not all browsers fully support this technology, so you should have a “spare” old-school option for this case);
• on the touch-devices click handlers lead to a delay of 300-500 ms, which is quite a lot, so it’s better to use “native” handlers – ontouchend for these devices;
• use only the necessary parts of large frameworks (eg jQuery), but not the entire. It would be even better to use small frameworks (XUI, zepto.js, microjs);
• try to minimize the javascript in forms, it is better to use HTML5, where possible;
• another useful achievement of HTML5 is the use of databases that are stored on the client’s side. Among the existing solutions the most popular is indexedDB (hope that soon this technology will be supported by mobile browsers);
• use ajax (onhashchange – to control the history) and ask for only what you need to change;
• load the JS asynchronously to the main content;
• reduce the startup delay. For example, the Gmail Mobile team offered an interesting way of the “lazy” module’s load.

The essence of this method is that first you need to split large software modules into smaller, and distribute, which of them should be loaded at the beginning of page load, and which later. It is also important for “deferred” modules to load as they are being called with the users’ actions.


The value of optimizing the time of the page load is becoming more important now, when users are increasingly using smart phones for everyday tasks on the Internet.

It is interesting that most people who use smartphones are more intolerant to the slow work of the site. This is often associated with the specific tasks to be solved within a few seconds (for example, to specify the address of the restaurant).

It is also important to remember that our goal is to minimize the load time with minimal loss in functionality and usability.

To read original article in Russian click here

More inSplashnology

Privacy Preference Center