OK, so it's a fictional humorous example, but the fact of the matter is that mobile web content has grown far beyond simple text messaging. Looking around the train on my daily commute, it's odd to look at the people using laptops for web surfing, instead of mobile devices, and think of them as "old school." But mobile devices have made the leap to the primary information channel for millions of people worldwide. With the level of reliance that there is on all that rich content, it's critically important that your mobile applications focus on speed. And to do that, it helps to think lean.
Here are some basic, common sense guidelines to consider in designing mobile applications for speed:
- Limit white space: It sounds simple enough, and it can be. Content files that are smaller in size will transmit faster, and removing extra white space in content is a quick way to slim down the content.
- Watch out for the Cookie Monster: Cookies are a standard method for storing identifying data on the client to personalize the user experience on a site. Cookies present a dual problem in mobile web applications, however. For one, every server request contains the cookie information and thus results in extra overhead in the traffic, reducing performance. Also, many mobile devices don't accept cookies, so you can't rely on support for them across mobile devices. One answer for this is the new HTML5 and its support for DOM storage. (NOTE: the acronym here does not stand for "Document Object Model"). DOM storage offers some key advantages over cookies for mobile web applications; chief among them in terms of speed is that DOM data is not transmitted to the web server with every request. This reduces the additional traffic and increases speed. In addition, you can store much more data in DOM storage (5MB-10MB depending on the browser) than in a cookie. And unlike cookies, servers cannot access DOM storage at will; traffic flow and access in both directions is controlled by the client.
- Minimize the detours: Redirects (sending a user to another server to pull in additional information) can be flat-out brutal in mobile web applications. When rendering a page, having a redirect between the client and the HTML file will cause delays in downloading the page and rendering elements until the HTML document has arrived. Some redirects may be necessary, for example, in account authentication, but other redirects can happen unintentionally and you should be vigilantly watching for these cases. Some examples to avoid:
- Missing Trailing Slash – Failing to have a trailing slash in a URL will cause an unintentional redirect to the directory, assuming the URL ends with a directory name. For instance, http://mywebsite.com/somedir will cause a redirect to http://mywebsite.com/somedir/.
- Conditional Redirects – This is redirecting a user based on certain conditions (browser used, etc.) to a different section of a website, or a different site altogether. It's easier to develop in this manner, but again, it adds overhead and time for the user to wait.
- Missing Trailing Slash – Failing to have a trailing slash in a URL will cause an unintentional redirect to the directory, assuming the URL ends with a directory name. For instance, http://mywebsite.com/somedir will cause a redirect to http://mywebsite.com/somedir/.
- Pack before you move: This is a general guideline to minimize network traffic by reducing round trips, and includes practices such as:
- Batching data requests to send in a single batch
- Combining static images into a single image by utilizing sprites. This is useful for images that don't often change.
- Cache Ajax data – caching this data wherever possible will reduce the response time a user might have to otherwise endure waiting for that asynchronous data request to roundtrip over the mobile network.
- Batching data requests to send in a single batch
As always, I welcome your comments.
Since as we have restricted display area on a mobile phone, developing multi-level choices is not a intelligent option too. Keeping the menus at most up to one stage deeply without too many alternatives would be a good choice. This keeps the routing and activity around the application sleek and easy.
ReplyDelete