Mobile site speed optimization

Along with the growth of the mobile Internet, the need to optimize the speed of mobile sites is growing. Even the most modern smartphones on Android, iOS, WebOS, BlackBerry OS and others have processors with a frequency of no more than 1Ghz, and 3G speeds can be considered quite slow (download speed is 3 times less than DSL).

Mobile devices inherited the problems of “big” machines: from the number of http requests to the effectiveness of JavaScript.

Mobile Features

In addition to being often pocketed and easier to lose, there are several key differences between mobile devices and desktops:

• small screen resolution;
• slow connections;
• limited cache size;
• many different devices and form factors;
• low power processors;
• extensive HTML5 support;
• relatively new browsers (in this world they don’t know about IE6).

General recommendations

Mobile sites are inherent in most of the performance problems of “big sites,” so many of the listed techniques came from desktop optimization.

• use gzip to compress text data;
• place the CSS in the header of the HTML document, and JavaScript at the bottom of the page;
• combine javascript and css files that are used throughout the site. This will reduce the number of HTTP requests, which is extremely critical for mobile sites;
• use minimization and obfuscation of CSS and JavaScript code;
• JS and CSS which are used only once on the site, as well as small JS and CSS (up to 5 kB), it is better to include directly into the page, i.e. do not make in separate files;
• Many mobile browsers (for example, Android or Opera Mobile) have a general limit on the number of connections no more than 4-6. Using domain sharding for such browsers can only harm the speed of the site;
• At the same time, the Android browser supports HTTP pipelining, which allows you to send 3 requests to the server at once in one connection. Remember to make sure the server also supports HTTP pipelining;
• it is very important to compress files (without visible loss in quality) - use, for example, Smush.it - for more on this ;
• avoid or at least make redirects cacheable;
• for iOS, use Quicktime Reference Movies, this allows you to “give” to the visitor different video files, based on the capabilities of its Internet connection.
• Take advantage of WebSockets wherever possible (full support is currently 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 most modern techniques to optimize sites:

• HTML code should be extremely simple. Use HTML5 semantic elements, specify <! DOCTYPE html>, exclude optional xmlns attributes. Also try to reduce the number of divs and classes;
• try to use input less often, and if you use, then in HTML5 formats;
• use CSS gradients instead of background images - this will drastically reduce the number of calls to the server;
• CSS provides many other useful features, the use of which is more effective than images (shadows, rounded borders, multiple backgrounds embedded in the svg and canvas pages).

Image Optimization

Along with the fight against unnecessary calls to the server, it is very important to minimize the size of the downloaded files. In this perspective, image optimization is the most important element.

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

On mobile devices, screens have significantly lower resolutions than desktop screens. CSS allows us to determine the current resolution of the user's screen and, depending on this, transfer to it the version of the image that has a more appropriate resolution.
')

/* Screens bigger than 480px */ @media only screen and (min-device-width: 481px) { #header { background-image: url(header-full.png); } } 

The code above specifies that the user's screen width is greater than 480px and instructs the browser to download a header-full.png image with full resolution.
But the following code fragment, determining that the screen width is less than 480px, offers the browser a picture adapted to small screens:

 /* Screens smaller than 480px */ @media only screen and (max-device-width: 480px) { #header { background-image: url(header-small.png); } } 

As a result of this mutual understanding between the site and the browser, the size of the data downloaded to the mobile device will be significantly reduced.

However, above all, take care of the convenience of the user. Using the same principle (separate content for mobile and desktop devices), you can make the site enjoyable for users with high-resolution screens, while not harming other visitors.
For example, iPhone 4 users have become accustomed to the fact that on the screen of their phone must be high DPI images (eg 300). And if you want your site not to look miserable on Retina screens, you will need to prepare another separate set of high-resolution images and upload them using CSS Media Queries

 /* 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); } } 

This is exactly the case when you should sacrifice performance in favor of user convenience.

Optimization based on connection speed

Starting with the version of Android 2.2 Froyo, developers have the opportunity to receive data about the current type of Internet connection from the device. This is implemented using the navigator.connection object.

Here is an example of data received from a device that operates on a 3G network:

navigator = {
connection: {
"type": "4",
"UNKNOWN": "0",
"ETHERNET": "1",
"WIFI": "2",
"CELL_2G": "3",
"CELL_3G": "4"
}
};
Connection type is “4”, which corresponds to CELL_3G. Using a simple script, you can determine the type of connection and pass this information as a CSS class in the HTML element.

 // 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'; break; case connection.CELL_2G: // 2G connectionSpeed = 'lowbandwidth'; break; default: // WIFI, ETHERNET, UNKNOWN connectionSpeed = 'highbandwidth'; } // set the connection speed on the html element, ie <html class="lowbandwidth"> htmlNode = document.body.parentNode; htmlClass = htmlNode.getAttribute('class') || ''; htmlNode.setAttribute('class', htmlClass + ' ' + connectionSpeed); 

As a result, when defining a low-speed connection, we transmit optimized images to the visitor's browser using CSS:

 .highbandwidth .logo { background-image:url('logo-high.jpg'); } .mediumbandwidth .logo { background-image:url('logo-medium.jpg'); } .lowbandwidth .logo { background-image:url('logo-low.jpg'); } 

And yet you should not deprive users of choice (we will not be dictators). Therefore, it will be good in addition to the common choice:

• site version desktop | mobile desktop | mobile

Giving also a choice:

• connection speed: High | Medium | Low High | Medium | Low

Use simple rules - “if the pixels are not visible, they do not need to be loaded”, but at the same time “you should not decide for the user, we can recommend him”.

Caching

If in the case of desktops in most cases, the decision will be in favor of external files, then with mobile files it is most likely the opposite. Due to the small size of the cache, there is no need to talk about large and long-term savings. There are a number of tips to optimize the speed of reloading pages:

• cache ajax;
• set the file headers for the distant future (far-future cache expiration headers);
• Avoid cookies, use localStorage instead (cookies are sent by http requests, significantly increasing the size of the transmitted data). LocalStorage and SessionStorage are HTML5 technologies that are a more effective alternative to cookies. You can also store external CSS and JavaScript;

An important limitation for LocalStorage and SessionStorage is that they can only store data of type String. Therefore, the data should be pre-converted to a string format, and subsequently restored to the original using JSON.stringify() and JSON.parse() :

 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); 

The size of the data that can be stored in these objects vary from browser to browser, but 5 Mb should be enough for most.
An interesting point is that devices on Android and BlackBerry OS can keep the cache even after turning the device on / off, while the iPhone cannot boast with it.

Smartphones	iPhone 4	Galaxy s	Nexus s	Blackberry torch
OS / Ver	iOS / 4.3	Android 2.2	Android 2.3	Blackberry 6
Constant*	0	four	four	25
In mind**	100	four	four	25

Tablets	iPad 1	iPad 2	XOOM
OS / Ver	iOS / 4.3	iOS / 4.3	Android 3.0
Constant*	0	0	20
In mind**	20	50	20

* Permanent - this is the cache that remains, even after restarting the browser.
** In memory is a cache that is stored in RAM (for example, when switching between applications). You can read more about cache in mobile devices in the Blaze company blog .

Javascript optimization

The lack of power of processors in mobile devices, again makes the struggle to reduce the load. So Google’s research shows that parsing every 1 KB of JavaScript code is approximately 1 ms.

• avoid javascript timeout animations, use CSS3 transitions instead (but not all browsers fully support this technology, so you should have a “spare” old school version for this case)
• on touch devices, click handlers lead to a delay of 300-500 ms, which is quite a lot, so for such devices it is better to use “native” handlers - ontouchend;
• use only the necessary parts of large frameworks (eg jQuery), and not their entirety. It is even more optimal to use small frameworks (XUI, zepto.js, microjs);
• strive to minimize javascript in forms, it is better to use HTML5, where it is possible;
• Another useful HTML5 achievement is the use of databases that are stored on the client side. Among existing solutions, indexedDB received the most popularity (we hope that this technology will soon be supported by mobile browsers);
• use ajax (onhashchange - to manage history) and ask only what needs to be changed;
• load JS asynchronously to the main content;
• reduce starting delays. For example, the Gmail Mobile team offered an interesting way to “lazy” loading modules ;

The essence of this method is that you first need to break up large software modules into smaller ones and distribute which of them should be loaded at the start of the page load, and which later. It is also important that “deferred” modules will be loaded as they are invoked by user actions. Such a load really looks lazy: until you kick it, it won't move.

Conclusion

The importance of optimizing the speed of mobile sites is becoming more important now, when users are increasingly using smartphones to solve everyday tasks on the Internet.

Interestingly, most people are more intolerant of slow sites when using smartphones. Often this is due to specific tasks that need to be solved within a few seconds (for example, specify the address of the restaurant).

It is important to remember that our task is to minimize the download speed of the site with the least loss in functionality and usability.