#VelocityConf: Speeding up Your Mobile HTML5 Experience

Talk slides and resources

As usual, Max Firtman did an excellet talk on mobile HTML5. Luckily for him, the space changes so much that he can give a talk on the same topic every year.

The slides and resources are good, so I just want to point out a few things.

If we take the convention that 1 second is a fast page load and 100ms is a fast interaction response, the latency of mobile devices is pretty terrible with 2G topping out around 1 second and even 4G topping out around 180ms. When you consider that the radio might be idle, this gets even worse.

He also covered a lot of things that are good practices. The one I liked the most was his investigation of responsive design. In my job, we have mostly written it off as sending too much data only to have it hidden. He went further and pointed out the conditionals for IE that will never be needed on mobile. The large images and tons of unused CSS just make it more absurd. I fully agree with his statements to focus on mobile and do it well.

Velocity 2011 (#velocityconf): HTML5 vs. Flash for video

The last really interesting talk I attended was about YouTube's use of Flash and HTML5. They had some really interesting issues that they have had to deal with. Plus, there are some really odd side effects that they both observed and intentionally caused.

First, they are at the point where the two versions are functionally similar. The HTML5 version of the player does not have quite as many features, but you can try it out by going here. The biggest feature gap is in rights management. Currently, Flash has a proprietary rights management system to protect the content. HTML5 lacks that sort of protection now. Otherwise, there is no reason why the two versions should be different for very long.

The most interesting part of the talk was around the performance differences. HTML5 generally outperforms the Flash version of the player in actually getting loaded and up on the screen. They were saying that the difference was about 200ms. However, once the play button was pushed or there was a seek, the Flash player usually started playing about 2 seconds faster. This isn't really because Flash is better, though. It's because the edge cache doesn't have as many of the HTML5 versions of the videos because it is nowhere near as popular.

The problem remains, though, that Flash was slower on the uptake. They dealt with this by doing some strange hacks here and there. The most clever (and scary) of which was creating an image in a script block in the head tag that points to the CDN that holds the video. That way, the connection was already open by the time the page got to rendering the Flash widget. It's really clever, but I'd hate to see this be necessary for long.

There were a couple other cool things out there. HTML5 can actually do more exact seeking since it does not need to seek to a key frame. There was some tweaking on the API for controlling an embedded player since the HTML5 player has to be in an iframe. This tweak uses the postMessage method on the window, which I have never heard about. I want to look into that and its support. That could solve some of the issues we've had previously with communicating between a parent and an iframe on different domains.

All said, there was some interesting, funny, and scary stuff here.

Velocity 2011 (#velocityconf): Browser Talks

One of the cool things about this conference is that they had the 4 major browsers represented: Chrome, Firefox, IE, and Opera. Yes, Opera is a major browser, and it's a really nice one too (see earlier posts about my Opera experiment).

I missed part of the Chrome talk, but I did hear about some prefetching of link data to help provide a snappier response when you navigate around the web. The obvious question of ad tracking came up. I also worry about the poor site that happens to be featured on a major page on the web. They not only get the clickthroughs, but they also get the pain of the traffic that never actually arrives, as it were.

The Firefox talk focused a lot on the features of HTML5 and customized JavaScript APIs that are being added. The upgrades are looking really good. Apparently Firefox 5 is going to be launching in a couple weeks. 6 and 7 are later in the year, but they are apparently only 6 weeks apart. I appreciate the faster development cycles and getting upgraded browsers into users' hands quickly. However, I don't like the break from Firefox's sensible numbering scheme. Chrome does the versions like this, but I like that Firefox, IE, and Opera all come with really visible changes to the end user when they do major version bumps. In any case, the version number doesn't really matter. What I want to see is if Firefox will suffer the same problem that Chrome does with the upgrade path for its users. I don't want to have to support 10 versions of every major browser, all at different points in the implementations of the really neat upcoming features.

IE was up next with some nice graphs and demonstrations of IE9 performance, especially against IE8. This is really the second time I have seen this talk. The last time was before IE9 was actually released as a finished product. The leaps are definitely impressive. I have to compliment the two presenters I've seen on their poise. It is difficult to walk into a room of people who are almost always using Firefox and Chrome to talk to them about IE. For the actual content, the most notable part for me was the background compilation of the JavaScript. This uses the other cores that so many computers have these days to compile JavaScript even as you may be running the exact same code. The next time through, though, it will be faster because it will be running native code.

Finally Opera got some time in the sun. The funny thing is that Opera has actually implemented most of these things already. They don't have hardware acceleration in their browser yet, but they have done a lot of forward-thinking things since some relatively early versions. The talk was mostly about how Opera owns the mobile market. I like the idea of selling the typically reluctant developers on this by showing them how many of their users actually use Opera on mobile devices (whether mini or mobile). He also talked about some of the difficulties of sites that do not respect the X-Forwarded-For header. In any case, it was good to see Opera getting some time on stage to talk about their product. He had to rush through the Firefly information and mobile debugging towards the end, but those are both great features if you have never tried them before.

Velocity 2011 (#velocityconf): Mobile HTML5 performance

Max Firtman started off by saying that we are guilty and that users hate us. In fact, he hates us. Then, he gets down to business.

Most of the things we take for granted in desktop usage are worse in mobile applications (network, latency, hardware). The experience and context are also very different. The browsers will behave differently than their desktop counterparts. He put up the headers from a feature phone. The accepts header was absolutely obscene. It enumerated exactly everything that the device can handle. You'll never see that large a header on a desktop.

Mobile browser issues abound. There are tons of them, most of them limited. Some are proxied while others directly access the sites. Most of them have no documentation, name, or debugging tools. His suggestion for dealing with the lack of debugging tools (whether on the device or in an emulator) is proxies. His recommendations are Charles Proxy or Fiddler. The proxy can help you understand the network traffic that you would usually see in a waterfall chart. For real devices, he also provided some other options, but I think the proxy is probably the best option. He did provide an option for doing some on-device JavaScript debugging, but I am very suspect about the impact of the performance of the site's JavaScript.

For some statistics, not surprisingly smartphones are the smallest part of the market and the largest part of the usage. The inverse is true for feature phones.

"We need to forget about pixels." I cannot be happier with this statement.

He also mentioned (for the 2nd time I've heard it) not always being connected. The idea of having enough data loaded onto the device to continue using the device in a degraded way until the connection comes back is very interesting. When he expended on this, he talked about an application cache that can be built in so that you can load the page with no connection. It's cool, but the way to have a robust (and updatable) cache is to basically use your own. The base page has to be very small with a bit of JS to determine if the cache is dead. I don't really like that hack, but it may be the only way with how things have been implemented.

He makes a very interesting point about mobile versions of sites. First, you should not redirect. His United.com example shows that over 1 second was spent on the iPhone redirecting twice (once to www.united.com, and then to mobile.united.com). Second, the search engines don't care if you are providing different content on the mobile version of the site. We are always talking about these things on the desktop platform, but it applies even more to the mobile platforms.

There is also the problem of complexity. We can occasionally see difficulties in processing the DOM on desktop platforms. It's even worse on mobile. That processing time is precious. The same applies to CSS and JS parsing. Those are worried on desktop platforms. Imagine how much time they probably take on an older mobile phone. I can hear the batteries screaming.

It's kind of worrying (and comforting, perhaps) that the same issues come up in poor implementations on both desktop and mobile platforms. One example provided is a hyperlink with no href. This is just poor behavior in general.

He has some really interesting ideas about how to trim sites down. A lot of designers ask us to provide background images, icons, etc. that make the site look nice. It really hurts to get those complex designs on mobile devices, though. The design is often lost on the user. Since CSS3 supports gradients, you can still get a lot of the effects that people love to put in designs. Interestingly, the support of sprites and inline images are also heavily supported on mobile platforms. The difficulty here is that you need to figure out if the device requesting actually supports these features. Since this can change the CSS (and/or images) you provide to the user, you have to do this or risk breaking your user experience.

The cool thing idea he also provided was a way to use canvas to draw the arrow (sideways carat) that was used on the original design. Canvas can create a data URL so that you can use that in the same way you might use an inline image. Unfortunatley, this is only available on the latest versions of browsers for mobile platforms. I wish I could force people to upgrade their browsers (both desktop and mobile) so that I can use some of these newer features without all the pain of browser detection, which is traditionally so error-prone. That said, he makes a big point out of providing the experience but not being too concerned about the support level. This is easier said than done, but a well-created design will degrade gracefully without certain capabilities.