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:
- 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
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.
- 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.
- 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.
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.
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
onhashchange for history management. use html over json
over xml in terms of performances. HTML5 server sent
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.