karlcow

This is another interesting case, I have been dealing with today. When you try to access the Web site with a Mobile browser, the site redirects automatically to an unknown scheme: market

→ curl -sI -A "Opera/9.80 (Android 2.3.5; Linux; Opera Mobi/ADR-1202082305; U; en) Presto/2.10.254 Version/12.00" http://speedtest.net/

HTTP/1.1 302 Found
Date: Tue, 14 Aug 2012 12:21:49 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.8-1~dotdeb.2
Set-Cookie: stnetsid=05s7qegduk57818k4spc9tj651; expires=Wed, 14-Aug-2013 12:21:49 GMT; path=/; domain=.speedtest.net
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: market://details?id=org.zwanoo.android.speedtest&referrer=utm_source%3Dstnet%26utm_medium%3Dredirect%26utm_campaign%3Dstnet
Vary: Accept-Encoding
Content-Type: text/html

I have read today this long list of tips for Mobile Development. The tip about Detect and Redirect Users is not given with enough care outlining the issues related to user agent sniffing. So I left a comment. And I thought it might be useful for more people and I need to keep some of the points I made in there for memories.

Quite a list of tips. In the section “Detect And Redirect Users”, you recommend to use WURFL. It’s a choice which seems to be easy but which is in fact hard to maintain. There is a corollary of devices databases (any of them): It will break in the future.

The reason is quite simple, it’s a hard coded database of values. Browsers implementer not only evolve their browser engines but there are ported on more and more type of devices. One day or the other, you meet something which is not in the database and the site falls apart. Basically it is very fragile and not future friendly. People behind WURFL and other dbs make a tremendous and laudable work to maintain these lists, until the day they do not. For example, one of the major issues, Opera browser has right now is because of a library which is not maintained anymore and which was used in many ASP.net powered Web sites.

So as a strategy, it is a lot better to use feature detections. Through JS APIs the Web developers can detect what is supported by the Web browser and then you send the appropriate interactions. This with a combination of mediaqueries will be a lot better.

Another point is the fallback. When developing the site, people should really have a readable fallback. Basically I encourage people to create a dumb user agent in their favorite browser and if the site fails with this dumb user agent, then there is an issue. Because it means one day or the other it will happen for a browser which was not planned.

Web sites are deployed put in production and sometimes never touched again. That would be bad to have them break because there were not planned for being future friendly.

Mobile Web & HTML5 Performance Optimization

You are guilty. Users hate you. Mobile Web is slow, because developers are doing it wrong. There are issues such as slower networks, higher latency, slower hardware, different browsing experience, different context (beach, bathroom, in line, on the move, …). Browsers have different behaviours. For the same devices there are different possible networks with the same device. There are verbose HTTP headers for mobile browsers. There are browsers supporting 1, 2, 4, 6 parallel downloads. There are too many mobile browsers, some are too limited, and some are too innovative, some are proxied (doing transformations on the content). Some mobile browsers does not have documentation. Some of them do not have a name. And many browsers do not have debugging tools.

Features Phones (big market share) ← Social Phones → (big mobile web usage) Smart Phones

There are a few things to forget about:

• pixels
• static designs
• Desktop frameworks (not always)
• always connected
• unlimited power

A few things to learn about:

• server side detection
• progressive enhancement
• responsive design
• best experience for each context
• top-model approach

Users need to perceive speed. It’s not really the real speed.

For debugging there are only two browsers who have a debugging tool : Opera Mobile with Dragonfly, and the Blackberry on Playbook. Most of the emulators are not good such iOS. There are not real emulators. There are free. You will need a proxy such as proxy Charles Proxy or Fiddler. Proxies will modify the real experience. It is not exactly like the devices. There are remote debugging tools weinre, jdrop, mobileperf

Remote Labs such as deviceanywhere.com and perfectmobile.com. Nokia and Samsung have also these services. With Charles Proxy helps you with throttling by slowing down.

There are differences among devices for the support of html5.

Don’t be fanatic, be multiplatform.

Basically do not develop for one unique platform. Strange the speaker seems to associate the list of HTML5 devices with… OSes instead of rendering engines.

Some websites are too heavy for the mobile. As a result, people should think mobile first. A desktop website only doesn’t work for users. Mobile metatags and viewport will improve the experience. The speaker recommends server-side detection. I strongly disagree. There are PITA. People do not fix their web sites. WURFL gives server side detection.

Too many redirects kill the experience. united.com → www.united.com → mobile.united.com. Basically, it is important to not do it. It is important to deliver the homepage right away. In case it is absolutely necessary, only one redirect and cache it.

Simplicity is a key to success. Simple, semantic DOM will help. A complex structure will slow down the experience. New HTML5 rules and tags to reduce the load of useless nested div and span tags. Links without real href are likely to fail on blackberry phones where the JS has been disabled by the company.

United:

• XHTML: 18kb, 180 dom elements, 145 class definitions, etc.
• CSS: 137kb, 6700 lines, 681 selectors

Optimizing starts with very simple tips. Using the html5 doctype, no xml ns, no insane attributes, there are new elements such as article, section, footer, etc. When redoing the Web site of United.

United

• HTML5: 1.3kb, 31 DOM, no class, <1kb CSS

same design using CSS. If CSS is not there, no design but working.

It is important to compress the components with gzip. Caching is a good friend. Stylesheets at the top. reduce dns lookups, external css and scripts t be cacheable.

A resource is not necessary an HTTP download. We can reduce HTTP requests. Every request hurts a lot, specifically in the mobile space. The ideal would be closed from 1 only request initial load. Sometimes no request is possible. There are techniques for doing that.

Images have to be limited to only the necessary, no effects, no ornaments. It is possible to leave it plain. It will be better for the user anyway. Use the possibility of css 2.1 and css 3. Images can be compressed. An image with the right context for every devices is sometimes better.

colorzilla has a tool for creating gradients.

CSS Sprites help reduce the HTTP requests with a very good support on Mobile. There are services such as spriteme.org. DataURI is also a good way to save an HTTP request.

For some very simple images, it is possible to use canvas drawing API and use toDataURL() method. Using Canvas it is even possible to download images and cache them locally instead of the originating server. It is possible to use emoji codes which have been introduced on Unicode. There are available right now only on iOS.

Defer most of the code after onload, defer content, don’t even parse frameworks. If using a framework, be sure it is absolutely necessary. Parsing in Javascript takes time. from 1ms to 100ms per 1kb. Parsing JS delays onload. Commenting all code improves performances.

<script>/*…*/</script>

W3C Selectors API is available on the last generation of smartphones. Create your own mini-library. Use mini-framework. XUI, zepto.js, microjs.

United is using 3 framework on the homepage and two are not used.

Using cache is important.

<html manifest="offline.appcache">

It makes the application available immediately. Update process is tricky. HTML and resources into it, and then use localStorage for others. localStorage is easy and fast. Storing strings is twice faster than objects. It is possible to store images, code, styles, html elements and data. It can be mixed with cookies and create a resource storage library. On Mobile, it is possible to store until 2MB without issues.

Bing is using this technique.

On touch devices the click event is delayed in between 300ms to 500ms. It can be changed with ontouchend with a progressive enhancement technique.

Using AJAX, onhashchange for history management. use html over json over xml in terms of performances. HTML5 server sent events.

Basically do not decide for the user. The users may have a context that will enable them to enjoy the experience the way they want. W3C Network Information API will help to test the quality of the network.

Looking at Tunisia Mobile browsers statistics, there was a surprising spike in the curve. I wondered what could be the reason of this sudden increase. As you may know, Tunisia went recently through a lot of political events. Citizens revolted against the president and a new temporary government has been put in place. There are details on the English wikipedia page about the events but if you can read French, I would recommend the French version. I was wondering if the spike was due to more people in the street and then using a mobile browser. In fact, it is difficult to know. The spike starts on January 13 when the now former President announced he will not run again for the next elections and promise the Press and Internet freedom. This didn't put an end to the uproar of citizens and the next day, fights between the army and the citizen were happening in the streets.



I still wonder why this spike has happened, maybe the people, maybe something else. It is difficult to know. Opera Mini using big proxies through the world has been used sometimes to bypass the local censorship. (Update Opera Mini servers were used to be blocked in Tunisia. That might explain the spike if suddenly the users had access to more resources on Internet.)

The mix of social and technology changes has always fascinated me.

Update 2011-01-26: Wikipedia entry on Internet censorship in Tunisia