Mobile Web

Content Delivery Networks in the Mobile Web era

Everybody likes their Internet fast. Content delivery services (Akamai, Limelight and others) speed up the Web significantly, distributing your media across a global network of caching servers. It’s very likely that the end user is closer to an Akamai mirror than to the origin server, so the experience is improved significantly.

Enter the age of mobile web. At Mobify, we believe that every link on the Web should present an amazing mobile experience. One way to do this is by making content management systems mobile-aware. When the CMS detects a mobile user, it launches an alternate rendering path and generates new HTML server-side. This new mobile web page is then presented to the user – for a great example check out WPTouch, the most popular mobile plugin for WordPress.

The problem is, most content delivery networks don’t bother telling the origin server about mobile users, serving whatever is cached for the URL. And why should they? The whole point of CDN cache is reducing the time it takes to access web content. Plus, when not done properly server-side mobile rendering can actually be worse than the desktop website, as this comic illustrates.

So, what to do? Akamai allows limited code execution right on its edge nodes with EdgeComputing, but this is counterproductive for today’s agile web companies. Mobify’s Studio service relies on JavaScript to detect mobile users, redirecting them to the “m-dot” version of the same URL which is cached separately (see it in action by going to wired.com or newyorker.com on mobile; both use Akamai). In the future we’re going to see even more mobile rendering shifted into the browser, powered by JavaScript and HTML5. This brings the best of both worlds – responsive client-side apps that can be stored on a CDN for optimal performance (we use Amazon Cloudfront).

In my next post, I’ll try to guess why Matt Mullenweg doesn’t use WPTouch on his beautiful personal blog and share some of the things we learned about Drupal 8 from Dries’ DrupalCon keynote. Stay tuned!

Evolving Mobify Studio – Part 2

The previous post in the series described the design of Mobify Studio, and how it fit the mobile market in 2008. This post will examine changes to those assumptions caused by a changing mobile market and reveal the improvements made possible by proliferation of new devices.

In past three years, devices with high-quality browsers captured most of the market. iPhone, Android, and Blackberry 6 browsers are now competitive with desktop ones in correctness of Javascript and CSS implementations. Meanwhile, increased use of mobile social networking, as well as bookmark sharing and synchronization, made use of m.yoursite.com a problem. Today, a URL can pass through multiple services used by both mobile and desktop users.  Making sure that user ends up on correct URL for their platform is becoming more and more difficult. In addition, having a separate mobile domain introduces SEO concerns, requires additional SSL certificates and DNS configuration, and gets even more complicated when more device types are added  (tablet, TV).

These changes made us revisit the original assumptions. Our toolkit is now expanded to include complex JavaScript processing, and use of m.yoursite.com can hinder deployment, URL sharing, and use of SSL encryption. So, we started thinking about serving a single copy of website to both desktop and mobile users, and using JavaScript to transform it into mobile form. This approach can remove a whole lot of issues, in exchange for a single big one: how can we make this work correctly and quickly?

The most obvious way to transform a website on the client-side is by using override stylesheets for CSS (possibly delivered through media queries), and JavaScript content rewriting for HTML. The difficulty with this method is that all resources (images, scripts, stylesheets, frames) start loading as they are parsed, and browsers give us no reliable tools for preventing or canceling HTTP requests. So, if one was to modify the page after its markup finishes parsing, the resulting mobile page will load all the desktop resources, all the mobile-specific ones, and spend CPU time on extra processing. Since mobile browsers load few resources at a time and suffer from higher network latencies (especially on 3G), this is a recipe for unacceptably low performance.

To maintain reasonable performance, our client-side solution would need to exercise control over which resources are loaded before rest of the browser can see the resource and start an HTTP request. This requires overriding default browser behavior of fetching every resource as soon as its HTML tag is parsed in the document. We have figured out a way to accomplish this in the new Mobify product.

The webpage includes Mobify script snippets that lie dormant most of the time, but initialize and capture page content as text if they detect a mobile browser. As a result, the captured content is not processed by the browser, preventing it from issuing HTTP requests or executing unwanted Javascript. Now, transformation code can build the mobile page out of fragments of desktop one, and load just the pieces that are needed. Finally, the newly constructed markup is injected into page itself and has the desired external resources re-enabled, resulting in the complete mobile page.

As a result, mobile and desktop pages can live at same URL despite using drastically different markup and resources. We already do have some websites using this technology, such as http://alibris.com, http://kiwicollection.com, and http://threadless.com. In future posts in this series, we will describe the lower-level technology used to perform content escaping and transformation, and provide details on tools that the mobile page author can use to control inclusion of HTML and external content.

Wired.com Mobile Traffic Reaches 7%

[blackbirdpie url="http://twitter.com/evanatwired/status/30428593892884480"]