Web engineers who are serious about performance know that the majority of the web-performance bottlenecks are in the frontend. The biggest issues are the number of HTTP requests, heavy external resources, and blocking the UI thread resulting in either a momentary Flash Of Unstyled Content (FOUC) or the perception of an unresponsive site. A fast website equals better search engine rankings, higher conversion rates and even saves costs.

In this post, we’d like to talk about how we tackle the problem of reducing the number of HTTP requests. Compared to optimizing heavy external resources and unblocking the browser’s rendering engine, these are easier to make and have the biggest impact on performance.

If you’re ready to bring these performance enhancements to your website today, check out Mobify Cloud for free.

Thinking about HTTP Requests

The ideal case is of minimizing HTTP requests is to have two requests: one for an external script and one for an external stylesheet. Why?

• Every external script file has the potential to block the DOM tree construction as scripts can have a document.write that changes the DOM.
• Browsers stall when they encounter an external stylesheet because CSS files can have embedded @imports (or lead to the aforementioned FOUC, which is bad user experience.)

In fact, Steve Souders, the guru of website performance recommends that we avoid @import for high performance websites.

The problem with increased HTTP requests is exacerbated on mobile as each HTTP request can have a high variance in latency. It has become crucial to have some kind of post-development build process to optimize external resources before deployment to production. In development, it’s a good practice to organize your application into several files as debugging a giant monolithic file is a pain.

At Mobify, these are the kinds of issues that we like to solve with automation.

We built a backend service called Jazzcat (Javascript and CSS Concatenation) to make it possible for every website to reach the ideal case of two HTTP requests.

Challenges with naive concatenation

As much as we might wish it to be simple, combining files is not as simple as appending the start of one file to the end of the previous.

In the case of Javascript, we’d like to isolate errors. The browser usually ignores the parsing and execution of a script if it finds syntax or runtime errors. In the uncombined case, the browser just moves onto the next one. With a single combined file, the rest of your scripts fail to execute if a single error occurs during the parsing of the file. Combining scripts files can also clobber namespaces and lead to unexpected side effects.

With CSS, the problem is different external files can have different character encoding. Most CSS files are encoded in UTF-8, and we're working on adding support for non-UTF8 character sets. Secondly, all relative URLs must now be rewritten to be absolute URLs. Thirdly, the CSS grammar only allows for @import statements at the very top of the file, so we’ll have to walk the dependency tree and “flatten” out the hierarchy of imports.

Jazzcat: a resource concatenator

Jazzcat is a backend service we built to concatenate resources properly dealing with the caveats mentioned earlier. Upon receiving a request with a list of resources to fetch, Jazzcat makes individual requests to your website. The responses from your website are appropriately encoded before being returned to the client making the request. As with any proxy, we need to deal with issues like missing resources, unresponsive/slow backends, etc. We are able to handle thousands of concurrent open connections thanks to the evented architecture of Node.js.

The Jazzcat service itself is stateless, but we built a caching layer by putting a CDN in front of it. The CDN caches the combined files on distributed servers across the world, bringing it closer to the user. The CDN is also responsible for sending down gzipped versions of the final files to clients that support compression.

Taking caching to next level with Mobify.js

Mobify.js is our framework that helps you quickly adapt any website to any device. It's open-sourced under the MIT-license.

Besides providing a Javascript API within Mobify.js, we provide additional extensions to the Jazzcat service. We hit a different endpoint on the backend Jazzcat service to return a rich JSON data structure with the individual resources rather than a single combined file. The response is unpacked by Mobify.js and put into local storage.

The next time a web page tries to load a script, Mobify.js first tries to see if local storage has it before making a HTTP request. If that page on your site requires a different set of scripts, Mobify.js progressively reduces the files it needs to fetch before making a single request to Jazzcat to download the missing files.

In some ways, you can think of the single connection as a pipeline to Jazzcat to stream new resources (aside: both Google and Bing use local storage to improve the performance of their respective websites.)

Next steps

We’ve described from first principles how we attempt to reduce the number of HTTP requests, following best practices.

To make use of these advanced features, try the Mobify Cloud now for free.

And if you find this kind of work interesting, please consider applying to work at Mobify – we’re hiring.

A little over a week ago, we announced that we’re open-sourcing Mobify.js, our framework that helps you quickly adapt any website to any device under the MIT-license. The immediate reactions from the front-end community were exciting and encouraging.

In this post, we’d like to fully explain the history behind Mobify.js, what it is, what it comes with, where it’s headed and why you should use it if you’re building mobile websites. If you’re ready to start using it right away, check out the Mobify.js homepage or Mobify.js on GitHub.

History

At Mobify, we started with the vision to make the web better on all devices. As we say, "To Mobify the Web." Our first product to mobify the web was a proxy-based solution that was cutting edge in 2008. It provided a mobile version of the website at m.yoursite.com and over fifty thousand people built mobile websites on this product.

Over time, as we built larger websites, we started to discover the limitations to the proxy-based solution. The limitations hit us hard one morning after we’d been up all night trying to setup servers to meet PCI compliance. We knew there had to be a better way to build amazing mobile websites.

We started the Mobify.js project internally to provide an alternate solution and answer these inconsistencies across devices. As we built it we could see there was a need for a framework that went beyond building mobile website, but to adapt any website to any device. Mobify.js is now being used to power millions of daily mobile and tablet visits to sites like Starbucks, ideeli, Beyond the Rack, and lululemon.

What is Mobify.js?

Mobify.js is a framework for client-side adaptation of any site to any device. It consists of four key parts:

• a JavaScript snippet that does device detection and bootstraps the adaptation. This is known as the Mobify.js tag and needs to go right after the head tag.
• the tag loads the Mobify.js payload file that contains a series of operations that adapts the DOM constructed from the original source to an object that can be rendered with client-side templates. This final HTML produces a DOM that you see on your mobile browser.
• mobify-client, which is a cross-platform command line program that runs within the Node.js runtime for creating fresh projects, building for production and deploying Mobify.js projects.
• a set of modules that contain common, reusable design and code elements that serve as a showcase of building for mobile first. These modules have been tested across a wide range of devices and should significantly speed up development.

Since the adaptations are all run client-side, every page on your site lives at a single URL. Avoiding duplicating your content on another URL (i.e., m.yoursite.com) is great for SEO, social media sharing and user experience. You also don’t run the risk of your mobile site falling out of sync with your desktop site.

What's inside Mobify.js?

To get started with Mobify.js, we install the mobify-client through the node package manager. This package is comprised of two repositories: mobifyjs and mobify-client. The former includes the client-side adaptation code such as the templating language and the latter includes tools to build Mobify.js for production including concatenation and minification.

Mobile Templating Language

Mobify.js uses an asynchronous, lightweight and fast Javascript templating language built over Dust.js. We picked dust.js for its high performance, maturity, documentation and ease of use. Linkedin has done an extensive study on dust.js which is worth a read. Note that Mobify.js can be limited to the use of DOM adaptations only without ever having to create brand new templates.

Zepto.js

jQuery is one of the most popular JavaScript libraries out there, mainly because of its cross-browser support, going back all the way to IE6. However, the legacy support is a big portion of the codebase. Comparatively, Zepto.js is significantly smaller aiming to be in the 5-10 KB range, while still maintaining jQuery syntax compatibility. Zepto does this by cutting down the number of browsers supported (mobile is predominantly Webkit.)

We decided to ship with Zepto as bandwidth is a big issue on mobile. However, Mobify.js supports both jQuery and Zepto and we might decide to switch back to jQuery if they followed up on their plans to make it more modular.

Designer friendly class names

Mobify.js injects additional classes to a global wrapper like your site’s body tag to indicate properties about the mobile device environment. This includes information about screen size, operating system, pixel density and orientation. For example, the device orientation is presented by x-landscape and x-portrait, automatically updated when the orientation changes. To see how this works, check the source.

Batteries included

Mobify.js ships with two modules at present that were built from the ground up as mobile-first citizens. Most mobile web components like sliders and accordions that are widely used today are not meant for mobile and were hastily ported over from their desktop counterparts. Our modules were designed to be mobile-first and have been tested across a spectrum of devices. They come pre-packaged with markup, CSS styling and lots of examples to make it really easy to use. We will be digging into the philosophy and motivations behind our modules in a future post. Check out our current modules here

Production ready

The mobify-client comes built-in with a development web server, which compiles the API with your adaptations and templates on the fly for rapid development. For production use-cases, the mobify-client can build a highly compact version of Mobify.js using UglifyJS that removes comments, shortens variable names and does various other optimizations. The build artifact can be hosted statically by your webserver or on the Mobify Cloud Platform (which is free.)

Why should you use this?

Mobify.js provides a universal solution to building mobile websites. At Mobify, it’s used extensively across all of our customer sites and is flexible enough to work for many unique use cases.

It’s a simple way to build a clean and highly usable mobile website either from scratch or from an existing desktop site. Your adaptations are always described as deltas with respect to your desktop site, leading to shorter integration times.

The typical use-case is to use the mobify-client to compile a single payload file that is pushed to a content distribution network (CDN). The payload is cached on the device for five minutes so it doesn’t have to be re-downloaded on each new page request. We do quite a bit more front-end optimizations (e.g., the use of DOM storage) which we will be spilling out in the future.

Where is it headed?

By open-sourcing Mobify.js, we really want to empower developers to create great mobile experiences. If you’d like to help make Mobify.js better, feel free to fork it, file issues and watch its progress on GitHub. We aim to put out shiny new features every week, so keep checking back often to keep on top of what we’re up to.

You should also follow the Mobify.js team on twitter here.

For the first time, the product team behind Mobify had a presence at OSCON, the open-source convention hosted by O’Reilly. There was plenty to learn from the roster of over 300 speakers and the presence of so many eminent people and companies. Last but not least, the event took place in Portland, known for its famous craft-beer scene – we knew that thirst wouldn’t be an issue.

In light of our recent open-source release of Mobify.js, we thought we’d share some of the team’s observations from last week.

Diversity of Open Source Community

All of us were surprised by the diversity of companies present. Speakers and attendees from start-ups like Stripe, Braintree and Puppet Labs mingled with Unix hackers.

There were companies with databases, big data tools, security, cloud infrastructure amongst many, many others. All of them contribute a lot of the code that powers the Internet as we know it.

At Mobify, we’re excited to be a part of the open-source community, and glad we had the chance to soak in the energy.

Void in Front-End Development

At OSCON we encountered surprisingly few people focused on open source projects for the front-end overall, and mobile web in particular.

The open-source movement has been around for a long time, but the JavaScript scene has only bloomed in the past few years. Successful projects – Backbone, PhoneGap, Sencha and Meteor among them – are redefining how websites and apps are made. Yet they are at beginning stages of their development compared with the number of mature open-source software and hardware projects overall.

We want to lead the maturing of front-end development within the open-source community. The best way we see to do this is by contributing – we’re looking forward to open sourcing more useful code, adding to the conversation about design patterns and sharing best practices for building the mobile web.

Community Management Wins in Open Source

It’s clear in that community management makes or breaks an open-source project. Besides code itself, a lot of effort has to go into coordinating and growing the team behind it, as well as building a good foundation for contributors.

It’s also clear that contributions to open source projects happen in code and beyond: design, documentation and evangelism also count towards success.

Building a thriving community is hard, but rewarding work. The biggest successes we see (like PhoneGap Day below) have vibrant communities with developers inspired to create amazing work and having fun.

If you’re going to start an open-source project, make sure community building is a key priority.

PhoneGap Day – Big Success For Mobile Apps

The most interesting event for mobile developers and designers at OSCON was definitely the PhoneGap day, hosted by our neighbors at Adobe/Nitobi. It was a day packed with fun and information with the core team behind PhoneGap and the community around it.

The PhoneGap project has evolved in a big way from its launch in Vancouver four years ago and now features plugin functionality, better emulators and compatibility with more devices. If you’re a developer looking to build a native app quickly – PhoneGap is for you!

Overall, we really enjoyed the trip to OSCON and look to come back next year. In the meantime, expect more great features in the open-source release of Mobify.js!

Hello from PDX!

Our entire mobify.js platform team is down in Portland this week for OSCON, the largest open source convention -- with many thanks to O'Reilly for their commitment to open source, their fantastic safari of great books and for organizing a great conference. It’s tremendously exciting to learn and see what’s happening in the broader community.

While there are vibrant communities around big data, programming languages, and mobile app frameworks, we found there was a void when it came to mobile website performance and best practices. We think there’s an interesting discussion to be had there, so we're creating a space where developers can talk about sharing design patterns, approaches and best practices for the web on a variety of devices.

To kick start the conversation, we've created and open sourced mobify.js under an MIT license.  Mobify.js is our approach to adapting any website to any capable web device.  Today we've been focused on tablet and mobile, but the technology is inherently extendable and uses web standard components to complement responsive design and other web community initiatives for how to design & develop for the increasingly complex device ecosystem. Mobify.js represents an innovation over many other approaches because of its client-side focus.  With adaptation done at the presentation layer, client-side, but with granular control over resources, there's an enforced separation of content from presentation with the commensurate benefits & control this brings. One of the most significant of these benefits is the "DRY principle", or, "Don't Repeat Yourself" -- it means not having the same content in two different places, ever. On the web, this has a direct, tangible effect on social media sharing, SEO & user experience.

Over the next few weeks, we're going to be digging into the nuts and bolts of our technology. We'll also share tricks of the trade, lessons learned, and show how mobile front-end technology will be changing the landscape of how we think about designing web content going forward. Let’s hear from our readers! What mobile web development topics would you like us to discuss?

The whole team will be present at PhoneGap day on Friday. We'll be wearing black T-shirts, and yes, they say Mobify on them. Please come say hi!