Table of Contents for

High Performance Responsive Design

So far, we have looked at web performance patterns and anti-patterns in the world of responsive design. We’ve looked at crafting our own solutions to implement these patterns of best practices, both from the client side and the server side. Chapter 6 shows how to create automated tests via PhantomJS to verify the adherence to our performance-responsive design patterns and include them in a continuous integration (CI) workflow using Jenkins. In this chapter, we will explore some of the frameworks that are available, and analyze how they handle web performance. Different types of responsive frameworks exist: there are boilerplates that give predetermined page layouts; there are grid systems that just define responsive grid layouts; and then there are complete solutions that include different page layouts with reusable modules, web fonts, and JavaScript functionality.

If you look at the overall landscape of frameworks, the first thing you’ll note is that they are all implemented for the frontend. In these frameworks, there will generally be predefined CSS that describes the styling of a module such as a button or a grid, or even complex UI elements such as accordions and sliders and guided navigation. You can use these modules by assigning their classes to elements on your page. Some frameworks have a JavaScript API with which you can programmatically create styled elements on your page.

As of this writing, the biggest names in frameworks are Twitter’s Bootstrap and Foundation from ZURB. In fact, when we look at Google Trend to compare relative search interest in Bootstrap and Foundation to other frameworks, we need to create two different charts because the interest in Bootstrap is a full order of magnitude greater than interest in the other frameworks, which is amply illustrated in Figure 7-1 and Figure 7-2.

Figure 7-1. Comparing relative search interest between Twitter Bootstrap and ZURB’s Foundation framework

Figure 7-2. Comparing relative search interest in ZURB’s Foundation, Skeleton, and Semantic UI

In Figure 7-1 and Figure 7-2, note the difference in scale between the two Google Trend images, with Foundation being the common link between the two charts (the blue line in both charts).

We will begin by establishing criteria that we will be using to evaluate these frameworks.

Our criteria will be the following:

What patterns and/or anti-patterns does the framework use?

How easy is it to use?

What is the size of the framework, including dependencies?

What, if any, dependencies does the framework have, including dependencies on other frameworks or libraries?

Let’s commence the evaluation by first looking at Twitter’s Bootstrap.

Bootstrap is a frontend, open source framework created in 2011 by Mark Otto and Jacob Thornton at Twitter and is available at http://getbootstrap.com/. Figure 7-3 shows the Bootstrap home page.

Bootstrap’s base installation comes with predefined CSS and JavaScript to implement a set of frontend components that have responsiveness built in to them. These components include buttons, tabs, progress bars, grid systems, patterns for alerts, and even specific page layouts.

Figure 7-3. The Bootstrap homepage

The install consists of the directory structure, which you can see in Figure 7-4.

Figure 7-4. The core Bootstrap installation

Using Bootstrap is as simple as including the core CSS and JavaScript files on your page, and then you begin using predefined components. Also note that Bootstrap requires JQuery:

    <link href="css/bootstrap.min.css" rel="stylesheet">
    <script src="js/bootstrap.min.js"></script>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/
1.11.1/jquery.min.js"></script>

It’s easy to see why Bootstrap is so popular: in around 20 minutes, using the built-in components and styles from Bootstrap, I was able to construct the website shown in Figure 7-5 (it’s available at http://tomjbarker.github.io/).

Figure 7-5. An example website created in Bootstrap

The next framework we will evaluate is Foundation by ZURB, a design firm from California. Foundation was created and made available as open source in 2011. You can download it from http://foundation.zurb.com/. Figure 7-6 depicts the Foundation home page.

Figure 7-6. The home page for ZURB Foundation

Downloading and unzipping the framework creates the directory structure shown in Figure 7-7.

Figure 7-7. Tree view of the Foundation installation

Just like Bootstrap, Foundation comes with prestyled components, including media queries to handle different viewport sizes. Also, like Bootstrap, pages are arranged in rows and columns with CSS classes assigned to <div>s to specify explicit grid structure and which component to load.

Using the built-in components from Foundation, I constructed the website presented in Figure 7-8. You can look at the site at http://bit.ly/10RjT1n. Table 7-2 provides the evaluation data.

Figure 7-8. A website created by using Foundation

Let’s look at how Foundation fared, see Table 7-2.

Skeleton was created and released in 2011 by Dave Gamache, formerly of Twitter. You can download it from http://www.getskeleton.com/. Figure 7-9 shows the Skeleton home page.

Figure 7-9. The Skeleton home page with instructions and inline code examples

If you download and unzip the Skeleton framework, you can see that it is more of a boilerplate, with an index.html page for us to edit and an existing directory hierarchy with the necessary CSS and images that the code references. Figure 7-10 illustrates the unzipped Skeleton directory tree structure.

Figure 7-10. Skeleton website boilerplate, unzipped

Whereas Bootstrap comes with prestyled components such as the Jumbotron, Skeleton takes a much more minimalist approach. There is barely any styling to speak of; mainly it offers just buttons, forms, and typography, along with layout definitions. The idea is to use Skeleton for minimal layout and layer your own styles on top of it.

Using the included boilerplate, you can construct a website similar in structure to the previous examples, styled in in the minimalist vein of Skeleton, as shown in Figure 7-11. You can obtain Skeleton at http://tomjbarker.github.io/skeleton/.

Figure 7-11. A website created by using Skeleton

Semantic UI is another web framework, again implemented on the frontend, that provides prestyled UI components with client-side responsiveness built in. It is available at http://semantic-ui.com/. Figure 7-12 presents a screenshot of the Semantic UI home page.

Figure 7-12. The Semantic UI home page

From the home page, you can download a ZIP file that contains the directory structures that shown in Figure 7-13. There is an examples directory that contains a couple of sample pages that demonstrate how to use the framework, a less directory that contains individual LESS files for each component, a minified directory that holds individual minified CSS files for each component. There is also a packaged directory that contains all of the UI components and the JavaScript API aggregated into a single CSS and JavaScript file (plus the minified version of these packaged files). Figure 7-14 shows the contents of the packaged directory. Finally, there is an uncompressed directory that contains all of the individual components as (uncompressed) CSS files.

Figure 7-13. Tree view of the directories in the Semantic UI download

Figure 7-14. Tree view of the packaged files from the Semantic UI download

In Figure 7-14, observe that the download also included CSS files for individual components so that we can choose to only utilize the files for the modules that we are using

Using the packaged CSS and based on the homepage.html example from the download, I was able to construct the example website displayed in Figure 7-15. The example is available at http://tomjbarker.github.io/semantic/.

Figure 7-15. A website created using Semantic UI

When you compare the raw numbers, you can see that from the pool of frameworks that we’ve looked at, Semantic is the heaviest of the group—if you are using the packaged files and not cherry-picking components to include. Figure 7-16 provides a side-by-side comparison of the sheer size of the frameworks.

Figure 7-16 illustrates clearly that the sizes vary drastically, from 13 KB for Skeleton, up to 448 KB for Semantic UI. Taking this a step further, if you then look at the example websites using these frameworks—all with the same exact content—and look at the total payload for each site, breaking out the total payload for each asset type, you can see that the page size gets inflated from 460 KB, in the case of our Skeleton example, up to 907 KB for our Semantic UI example. Figure 7-17 depicts this break out.

Figure 7-16. Framework payload comparison

What is evident in Figure 7-17 is how the size of the frameworks impact the size of the overall page payload, where the red segments represents the size of the frameworks, whereas the blue segments represents the size of the HTML needed to create the pages, and the yellow segments represent the size of the images used in the pages. Notice that all the pages use the same images, and require roughly the same amount of HTML (within a 2 KB difference) to implement.

Figure 7-17. The impact of framework sizes on page payload

When I surveyed the landscape of responsive frameworks, it became clear to me that they are all frontend frameworks, and with the exception of Skeleton, they are not designed with performance in mind. Armed with this knowledge, I decided to create a bare-bones boilerplate using NodeJS to set up a full-stack responsive website using the principles that we have been discussing in this book. I named the boilerplate Ripple, and made it available for you at https://github.com/tomjbarker/Ripple. Following is the source code for Ripple:

var http = require("http");
var url = require("url");

var handle = {}
handle["/"] = checkUA;
handle["/favicon.ico"] = favicon;

var uaViewPortCategories = {
    "320": new RegExp(/Nexus S|iPhone|BB10|Nexus 4|Nexus 5|
HTC|LG|GT/),
    "640": new RegExp(/Nexus 7/),
    "1024": new RegExp(/Silk|iPad|Android/)
};

var assetPath = {
    "css": "assets/css/1024/",
    "img": "assets/img/1024/",
    "js": "assets/js/1024/"
};

var serv = http.createServer(function (req, res) {
    var pathname = url.parse(req.url).pathname;
    route(pathname, res, req);
});

function route(path, res, req){
    console.log("routing " + path)
    handle[path](res, req);
}

function checkUA(res, req) {
    var ua = req.headers["user-agent"]
    var re = new RegExp(/iPhone|iPod|iPad|Mobile|Android/);
    if(re.exec(ua)){
        getMobileCapabilities(ua, res);
    }
    renderExperience(res);
}

function getMobileCapabilities(ua, res){
    res.writeHead(200, { "Content-Type": "text/html" });
    var viewPortWidth = 1024;
    if(uaViewPortCategories["320"].exec(ua)){
        viewPortWidth = 320
    }else if(uaViewPortCategories["640"].exec(ua)){
        viewPortWidth = 640
    }else if(uaViewPortCategories["1024"].exec(ua)){
        viewPortWidth = 1024
    }

    assetPath.css = "assets/css/"+viewPortWidth+"/";
    assetPath.img = "assets/img/"+viewPortWidth+"/"
    assetPath.js = "assets/js/"+viewPortWidth+"/"
}

function renderExperience(res){
    res.writeHead(200, { "Content-Type": "text/html" });
    res.write(assetPath.css + "<br/>");
    res.write(assetPath.img + "<br/>");
    res.end(assetPath.js);
}

function favicon(res, req){
    res.writeHead(200, {
'Content-Type': 'image/x-icon'
} );
    res.end();
}

serv.listen(80);

To run the boilerplate, simply download the project from GitHub, change directory into the project directory, and then run the engine.js file from node, as follows:

node engine.js

The engine file checks the User Agent from the HTTP request, runs a series of regular expressions against the User Agent to determine the client, and based on the determination creates paths to static assets that are appropriate to the viewport size of the client device.

As of this writing, all of the frameworks available are frontend frameworks. With the exception of Skeleton, most are heavy—some would say bloated—and all follow the same anti-patterns of loading the same assets for every device experience.

Again, as of this writing, there are no mainstream server-side frameworks or boilerplates available; if you are interested in what you’ve read so far and want to explore the concepts further, I hope you will check out Ripple and begin exploring the performance benefits that can be gained from focusing on responsiveness from the server side.