Modern Mobile Web Development: Breaking the rules, beating delays, improving responsiveness and performance

I spent most part of this year working in Service Workers for the New Gaia Architecture (NGA) that Mozilla is preparing to release with Firefox OS 2.5 & 3.0. This is the first of a series of articles about the effort we are putting in evolving Gaia while contributing to best programming practises for Modern Mobile Web.

More than an architecture, NGA is a set of recommendations to reach specific goals, good not only for Firefox OS applications but for any modern web application: offline availability, resource efficiency, performance and continuity. Different technologies exists (and other are coming) to help reaching each target.

Although, there is some confusion about how all these technologies fit together. Even inside the Firefox OS team some see pinning apps (which is a mechanism to keep and entire site cached forever and it must not to be confused with the concept of pinning the web) overlaps with Offline Cache. Other people see the render store unnecessary and overlapping with the prerender technology. If this is your case or simply you did not know about these concepts, continue reading, you deserve an explanation first.

Know your enemy

In this first chapter, before diving into technobabble, let’s see what NGA is trying to solve focusing on some aspects of the NGA goals, in particular, those related with performance and resource efficiency.

To reach resource efficiency, NGA advocates for recovering the multi page approach* of web sites giving each view a single responsibility. This not only fits with what we in Firefox OS call ‘pinning the web‘ (I strongly recommend to follow the link, it’s very entertaining) but it allows to keep optimal the usage of available resources by loading and executing what is needed for the current view only.

[*The content wrapper has disappeared in favour of prerender and transition API so views are actually isolated documents.]

Nevertheless, it introduces two serious problems for performance: it seems to break all those fancy iframe transitions to mimic UX flows and responsiveness from native applications and it introduces delays emerging from navigation and bootstrapping.

Responsiveness, or more accurate, user perceived performance is important. Simply put, perceived performance is the subjective measure of how well something is working. If the user touch on a contact to open the contact details, starting an smooth 60 fps animation for the transition between the two views, with delays no longer than 100 ms, give the sense of instantaneous reaction. Failing to meet these expectations translate to sluggish animations or unresponsive experiences.

Well, step by step. If your concern is about how awesome are your transitions when making iframes to enter from all directions, fear not. Let me show you a how the new NGA approach does not break transitions in this video (and slides) about the new Contacts app from my colleagues here at Telefonica. You see? No fancyness is lost. 🙂

But what about delay? If you navigate to another web page, that web page will start in a clean state. If we want to provide a good UX, we must meet the time limits from above. As a result, our goal will be to reduce the delay to, ideally, zero.

Divide and conquer is what I would say to address this challenge so let’s do a breakdown of all the delays involved into rendering when navigating. This is a pretty standard schema that you probably recognise:

1. Navigate to a new document.
2. Download resources (which includes the template).
3. Set your environment up (include loading shared libraries).
4. Query your API for the model.
5. Combine the template with your model.
6. Render the content.

We are talking now! These small pieces are key to beat delay. You probably already know some tricks: you know a good caching policy or the e-tag header reduce delay number 2. You know querying databases in batches reduces delay 4 and, of course, you know document fragments or more sophisticated virtual DOM backed strategies for updating UI improves delay 6.

Know your enemy, reads the title of the chapter, and now we know it. Let’s introduce our champions in the next chapters of the series at the same time we discover the strategy to make them work together!

(I want to thank Francisco Jordano for all the feedback and the title suggestion, and I want to thank all the fellow workers at the NGA team from Tef and Mozilla as well, for their effort and dedication).