otsukare Thoughts after a day of work

Velocity 2011 - Mobile Web and HTML5 Performance Optimization

by Karl Dubost
(Worked at Opera from 2010 to 2013)

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:

A few things to learn about:

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:

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

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.