Adapting To A Responsive Design (Case Study)

Advertisement

This is the story of what we learned during a redesign for our most demanding client — ourselves! In this article, I will explain, from our own experience of refreshing our agency website, why we abandoned a separate mobile website and will review our process of creating a new responsive design.

At Cyber-Duck, we have been designing both responsive websites and adaptive mobile websites for several years now. Both options, of course, have their pros and cons. With a separate mobile website, you have the opportunity to tailor content and even interactions to the context of your users, whereas a responsive website means better content parity for users and a single website to maintain.

Why Adapt To A Responsive Design?

Our redesign story starts in August 2012. Until then, our previous strategy of having separate mobile, tablet and desktop websites didn’t exactly perform badly; they drove conversions, and user engagement appeared to be good relative to our desktop website. I should mention that this strategy was borne purely out of the need to quickly tailor our ageing desktop website to the increasing number of tablet and mobile users at the time.

Our old separate mobile and desktop websites
We used jQuery Mobile to create our previous mobile-optimized website as a quick fix for the increasing number of mobile users on our ageing desktop website.

We produced our tablet and mobile websites specifically with users of these devices in mind — performance was our top priority. We wanted to improve on the loading time of our “desktop” website dramatically; the desktop home page was 2.2 MB, with 84 HTTP requests, and the mobile home page was still quite large, at 700 KB, with 46 HTTP requests. We had also designed the interfaces specifically with touch in mind, using jQuery Mobile to enhance the user experience with touch gestures.

Changing Our Approach

Despite this, several factors led us to decide that this approach was no longer sustainable for our own website:

  • having to support multiple code bases,
  • content management,
  • the emergence of new mini-tablets and “phablets.”

The first two were not ideal, but at least manageable. The third, however, was a deal-breaker. OK, so we could have designed a website optimized for mini-tablets, but with so many more Web-enabled devices of all shapes and sizes entering the market every day, it would have been only a matter of time before we needed to think about optimizing for new form factors.

We wanted our new website to be easier to maintain and more future-friendly for the inevitable influx of new form factors.
We wanted our new website to be easier to maintain and more future-friendly for the inevitable influx of new form factors.

It was at this point that we decided to completely overhaul all three websites and create a responsive design that would provide the best possible experience to all of our users, regardless of how they accessed our website.

Setting Goals for the Responsive Design

At the very start of this overhaul, we set ourselves some simple goals, or principles if you like, that we wanted to achieve with our responsive design:

  1. Speed
    Performance affects everyone.
  2. Accessibility
    It should work with no styles, backgrounds or JavaScript.
  3. Content parity
    The same content and functionality should be on all platforms.
  4. Device-agnostic
    Leave no platform behind.
  5. Future-friendly
    Cut down on maintenance.

Based on these goals, our starting point for the design was to review our existing mobile website and to use it as a base for our responsive design. We explored how we could enhance for wider screens, rather than attempt to squeeze our previous desktop website down to mobile.

We started by speaking to some of our trusted customers about what they liked about our website, what they didn’t really like, and what was important to them when searching for a digital agency.

We also used analytics data from our previous website, using a mixture of Google Analytics, Lead Forensics and CrazyEgg to help us better understand what existing users wanted and needed from our website. As a result, we were able to streamline and prioritize a content strategy based on how our users actually interact with the website.

Our design team used card-sorting exercises to help organize our existing content for the new website
Our design team used card-sorting exercises to reorganize our existing content for the new website.

Making Performance A Priority

A potential pitfall of responsive Web design, which you don’t find with a separate mobile website, is that performance can suffer, especially if you are simply hiding content using display: none at certain screen widths. We wanted to avoid this issue by putting the speed of our website at the heart of all design and technology decisions. The advantage is that a better performing website would benefit all users, not just mobile users.

To achieve this, we set a performance budget — a set of targets to improve the speed and size of our new website. For mobile users, we wanted a website that performed at the very least comparably to our existing mobile website; so, we wanted to load no more than 40 HTTP requests and 500 KB of data for our mobile breakpoint. (This was just the start. Our next step was to reduce this to less than 100 KB.)

Third-Party Scripts

The easiest way to trim the fat was to strip down third-party scripts as much as possible. According to Zurb, “to load the Facebook, Twitter and Google social media buttons for a total of 19 requests takes 246.7 KB in bandwidth.” As a result, we replaced heavy social-media plugins with lightweight social media links.

Replacing heavy third-party social buttons with simple links can significantly reduce HTTP requests and page-loading times.
Replacing heavy third-party social buttons with simple social media links can significantly reduce HTTP requests and page-loading times.

While some essential tracking scripts had to stay, we ensured that they would load after the content by putting them at the bottom of the body element in the HTML document and in an external scripts file.

Did We Really Need A CMS?

Early on in discussing the requirements for the new website, we considered whether we even needed a content management system (CMS). After all, as you’d expect in a digital agency, most of the team members are familiar with HTML, CSS and Git, so we could certainly manage our content without a CMS.

By using server-side performance-monitoring tools such as New Relic, we could see that our previous CMS was a key factor in the slow page-loading times. Thus, we took the fairly drastic decision to entirely remove the CMS from our website. We made an exception for our blog, which, due to the volume and frequency of content being published, still required a CMS to be managed effectively.

The previous website queried the database server 1,459 times with a total execution time of 2.34 seconds
The previous home page queried the database server 1,459 times, for a total execution time of 2.34 seconds.

Our old website was built with a model-view-controller (MVC) architecture that connected with the WordPress CMS. To give you an example, a typical page with WordPress uses around 600 to 1,500 queries to load; the database server is queried hundreds of times, and by simply removing the CMS, we managed to reduce this to zero in one fell swoop.

The team developed early prototypes to see how we could improve performance and responsiveness.
The team developed early prototypes to see how we could improve performance and responsiveness.

By removing the CMS for static pages, we eliminated the need for a database and dynamic templates. Using the popular PHP framework Laravel, we implemented a custom “dynamic route and static template” system. This means that each time a URL is called on our website, the Laravel router knows exactly which template to load by matching the URL to the template’s name, and the template already has all of the content laid out statically in HTML.

As a result of this alone, we managed to improve the processing speed of the website by over 3,900%. Taking the home page as an example, we improved server processing speeds from 2.2 seconds to 56 milliseconds on average.

Server execution speed is now only 56 milliseconds with zero database queries, approximately 40 times faster than before.
Server processing speed is now only 56 milliseconds, with zero database queries — approximately 40 times faster than before.

Naturally, this approach wouldn’t suit everyone (nor indeed many of our clients), but we should ask ourselves at the beginning of each project which CMS is most suitable, and whether one is necessary at all. Other options are out there, of course, including file-based CMS’ such as Kirby and Statamic, building or customizing a lightweight CMS such as Perch, or simply implementing better server-side caching such as with Varnish.

Ultimately, we decided to remove the CMS because even the most lightweight, highly optimized CMS with clever caching has overhead and cannot match the performance and server footprint of static files.

Avoiding Off-The-Shelf CSS Frameworks

While CSS frameworks such as Twitter Bootstrap and Foundation are great for quickly building interactive prototypes, they are often far more complex than we need for most projects. The reason is that these frameworks need to be sensitive to and cater to a wide variety of use cases and are not tailored to the particular requirements of your project.

We reduced the size of our style sheets by creating a custom responsive grid system that was simple, fast and extremely flexible to our needs.

We designed from the content out, meaning that the content shaped the layout and grid, as opposed to having the layout define the content.

Clockwise from top: The layout is three columns on a desktop, becomes a single column stack on mobile, and takes advantage of the extra space on tablets by floating the image to the left of the content.
Clockwise from top: The layout is three columns on a desktop, becomes a single column stack on mobile, and takes advantage of the extra space on tablets by floating the image to the left of the content.


@media only screen and (min-width: 120px) and (min-device-width: 120px) {

   // Uses mobile grid
   .container {
      width: 100%;
   }
   .col12, .col11, .col10, .col9, .col8, .col7, .col6, .col5, .col4, .col3 {
      width: 92%;
      margin: 0 4% 20px 4%;
   }
   .col2 {
      width: 46%;
      float: left;
      margin: 0 4% 20px 4%;
   }
}

@media only screen and (min-width: 600px) and (min-device-width: 600px) {

   // Uses custom grid to accomodate content
   .home-content {
      article {
         width: 92%;
         clear: both;
         margin: 0 4% 20px 4%;
      }
      .image {
         float: left;
         width: 40%;
      }
      .text {
         float: left;
         width: 50%;
         margin-left: 5%;
         .btn {
            @include box-sizing(content-box);
            width: 100%;
         }
      }
   }
}

@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {

   // Uses regular desktop grid system
   .container {
      width:960px;
      margin:0 auto;
   }
   .col4 {
      width: 300px;
      float: left;
      margin: 0 10px;
   }
} 

We used Sass for the front-end development to avoid any repetition of code, making sure every bit of CSS is actually being used. Sass can also minify the output to ensure that the CSS is a small as possible.


$sass --watch --style compressed scss:css

We also made use of functions within Sass to build our custom grid. Here is the code for the desktop grid:


@import "vars";

// Grid system
$wrap: $col * 12 + $gutter * 11;
@for $i from 2 through 12 {
   .col#{$i} {
      width: $col * $i + $gutter * $i - $gutter;
      float: left;
      margin: 0 $gutter/2 $vgrid $gutter/2;
   }
}
@for $i from 1 through 11 {
   .pre#{$i} {
      padding-left: $col * $i + $gutter * $i;
   }
}
@for $i from 1 through 11 {
   .suf#{$i} {
      padding-right: $col * $i + $gutter * $i;
   }
}
.container {
   width: $wrap + $gutter;
   margin: 0 auto;
   padding-top: 1px;
}
.colr {
   float: right;
   margin: 0 $gutter;
}
.alpha {
   margin-left: 0;
}
.omega {
   margin-right: 0;
}

From here, we could customize the width of columns and gutters within the grid simply by editing the vars configuration file.


// Grid
$vgrid:      20px;
$col:        60px;
$gutter:     20px;

The grid basically calculates the width of a span of columns based on the number of columns in that span, making it flexible to any configuration of layout or grid. We’ve open-sourced this code on GitHub (we make no apologies for the duck puns), so please fork and adapt this flexible grid system to your own project’s requirements — and let us know how it goes!

Conditionally Loading JavaScript

To further improve the speed of our new website, we wanted to load JavaScript only when it’s needed or supported. We achieved this by using RequireJS to ensure that JavaScript is loaded only after checking that JavaScript is available in the requesting browser and that the browser only loads scripts it can support. RequireJS also works as a module loader, ensuring that any JavaScript is called only if it’s needed on that page.

RequireJS also contains a handy optimization tool that combines related scripts and minifies them via UglifyJS to reduce the file size of the JavaScript.

The optimization reduced the JavaScript’s size from 411 KB to 106 KB.
The optimization reduced the JavaScript’s size from 411 KB to 106 KB.

Optimizing Image Assets

In addition to JavaScript, images are among the heaviest assets to download for most websites. We particularly wanted to improve on this area because our website is fairly image-heavy, showing examples that showcase our work.

We manually optimized images throughout the website by selectively compressing areas of images using Adobe Fireworks’ selective quality options. We also reduced image file sizes through further granular control of compression, blur and desaturation.

By de-saturating and blurring parts of images that are not essential we significantly reduced image sizes.
By desaturating and blurring parts of images that are not essential, we significantly reduced image sizes.

We also used ImageOptim and TinyPNG to compress our images and sprites. These tools remove all unnecessary data without compromising the quality of an image. This reduced the weight of the main image sprite, for instance, from 111 KB to 40 KB.

For the slideshow banner on the home page, we optimized for different screen sizes by using media queries to ensure that only appropriate-sized images are loaded.

On mobile, the slideshow items are far lighter

As you can see in the image above, on mobile, the slideshow items are far lighter.

The CSS:


@media only screen and (min-width: 120px) and (min-device-width: 120px) {
   .item-1 {
      background: $white url('carousel/dmd/background-optima-m.jpg') 50% 0 no-repeat;
      .computer, .tablet, .phone, .eiffel, .bigben, .train {
         display: none;
      }
   }
   /* Total loaded: 27 KB */
}

Meanwhile, on the desktop, we load more assets to make the most of the larger screen size available to us.
More assets are loaded on the desktop.

Meanwhile, on the desktop, we load more assets to make the most of the larger screen size available to us.

The CSS:


@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {
   .item-1 {
      background: $white url('carousel/dmd/background.jpg') center -30px no-repeat;
      .computer {
         background: url('carousel/dmd/computer.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-computer.jpg') center top no-repeat;
         }
      }
      .tablet {
         background: url('carousel/dmd/tablet.png') center top no-repeat;
         div   {
            background:  url('carousel/dmd/sc-tablet.jpg') center top no-repeat;
         }
      }
      .phone {
         background: url('carousel/dmd/phone.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-mobile.jpg') center top no-repeat;
         }
      }
      .eiffel {
         background: url('#{$img}carousel/dmd/eiffel.png') center top no-repeat;
      }
      .bigben {
         background: url('#{$img}carousel/dmd/bigben.png') center top no-repeat;
      }
      .train {
         background: url('#{$img}carousel/dmd/train.png') center top no-repeat;
      }
   }
   /* Total loaded: 266 KB */
}

Delivering Content Faster

Yahoo’s golden rule of performance states that “80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc.” In short, each request takes time to process; therefore, each request (such as to serve a file from the server) will inevitably increase the loading time.

By using CloudFlare’s content delivery network (CDN), we have separated the file-serving task of the Web server from the processing of the website. This means that our Web server concentrates on the application, rather than on serving static files. We moved all static assets to a separate subdomain (in our case, static.cyber-duck.co.uk) to reduce the cookies being sent with each request for an asset to a minimum, which in turn reduces the bandwidth required for each asset.

The CDN also caches and ensures that files are delivered from the server nearest to the user’s location, minimizing network latency (because the data is transmitted over a shorter distance), further reducing loading times.

In addition to the CDN, we used the Gzip rules and expires headers in the .htaccess file of HTML5 Boilerplate. This uses Apache’s mod_deflate module to compress the output of files to the browser and also sets an expiration on headers far into the future, to ensure better caching of the website for returning visitors.

Creating A Truly Responsive Design

As set out in our initial goals, we wanted our new website to have content parity and to provide accessibility to all users, regardless of how they access it.

In order to deliver a truly responsive design, we delegated all styling and display tasks to the CSS alone, using JavaScript to simply alter the “status” of elements by adding and removing CSS classes, as opposed to hiding and showing the elements with JavaScript directly.

The Right Code for the Task

Using this method, we could make mobile-specific optimizations, such as transforming the top menu on mobile to have telephone and map buttons so that mobile visitors can call or find our office quickly.

We used this approach throughout the website to activate and deactivate dynamic elements, always ensuring that these elements are still present on the page when JavaScript is unavailable. This way, we can offer content parity to our users while avoiding duplicate markup for specific contextual enhancements, such as those for mobile. With this approach, we ensure that JavaScript is an enhancement to the user experience, rather than a necessity to view the website.

On the right side of the top GUI, you can see the map and phone buttons, accompanied by the standard control to access the rest of the pages.
On the right side of the top GUI, you can see the map and phone buttons, accompanied by the standard control to access the rest of the pages.

Here is the JavaScript:


$('#menu').addClass('closed');
$('.btn-menu').click(function(e){
   e.preventDefault();
   $('#menu').toggleClass('closed');
});

The CSS for desktops:


.nav {
   display: block;
   float: right;
}
.btn-menu, .btn-call, .btn-map {
   display: none;
}

The CSS for mobile:


.menu {
   display: block;
   height: auto;
   overflow: hidden;
}
.menu.closed {
   height: 0;
}
.btn-menu, .btn-call, .btn-map {
   display: block;
}

Animations as an Enhancement

For the animated slideshow of our projects on the home page, we used SequenceJS, a plugin that gave us the freedom to create the slideshow using only HTML and CSS for the content. This way, whenever JavaScript is unavailable or the screen size is too small, we don’t have to download all assets for the animation, only those necessary for a smaller, lighter version.

Elsewhere, we decided to use CSS3 for animations. These enhance the user experience for browsers that support CSS3 animations, while older browsers still get the functionality, if not the eye candy. For example, when a user is on a latest-generation smartphone and expands the menu or a portfolio item, it animates with CSS3 rather than with JavaScript.

This improves the performance of these animations by using hardware acceleration, offloading tasks of the central processing unit (CPU) to the graphics processing unit (GPU). For smartphone and tablet users, this can make a massive difference to performance by reducing consumption of their already limited CPU resources.

Delegating animation to the CSS enables us to make the most of hardware acceleration.


.menu {
   height: auto;
   transition: height 200ms linear;
}
.menu.closed {
   height: 0;
   transition: height 200ms linear;
}

Breakpoints Based on Content and Design, Not Device

For the breakpoints, we used multiple CSS media queries to responsively deliver the optimal presentation of content to screens both large and small.

This device-agnostic approach ensures that we do not need to optimize the code later when other devices come to market. We included (though did not limit) breakpoints at 120, 240, 600, 760, 980 and 1360 pixels, as well as targeted media queries for specific content on pages and also high-pixel-density screens.

The website responds fluidly between each breakpoint.
The website responds fluidly between each breakpoint.

While we did not design breakpoints based on particular devices, in order to ensure further future-friendliness, we did test our website across as many devices and browsers as we could get our hands on, from the common (desktop browsers and a variety of phones and tablets) to the uncommon (Lynx, Playstation 3, Kindle Paperwhite, PSP Vita and others). We even tested the website on old Nokia devices, where the website still performed well.

Our designers and front-end team tested the new website on a wide variety of devices, including old models such as this Nokia X2.
Our designers and front-end team tested the new website on a wide variety of devices, including old models such as this Nokia X2.

Being More Accessible

Our responsibility as Web designers and developers is not only to make our websites more accessible, but also to educate our clients and colleagues about why they should care.

Below are a couple of quick wins for accessibility that we applied to our website.

Text

  • Text is legible against backgrounds, with a contrast ratio of 3:1 for headings and 4.5:1 for body text.
  • The text is structured with appropriate headings and in a meaningful order, and it describes the topic or purpose of the content.
  • Text can be resized without losing content or functionality.

Links

  • The purpose of all links is made clear with descriptive text and, when that isn’t practical, with alternative text.
  • The first link on every page bypasses the navigation to move straight to the content. This is hidden by default in a standard browser but is accessible in appropriate scenarios.
  • Page addresses (i.e. URLs) are human-readable and are permanent wherever possible.
  • We implemented access keys for quick navigation to important pages and features.

Here is the HTML for the “skip” navigation link:


<a href="#content" title="Skip to content" accesskey="s" class="btn-skip">Skip navigation</a>

And the CSS:


.btn-skip {
   position: absolute;
   left: -9999px;
}

Images

  • All content images have alternative text (with the alt attribute), which is shown where images are disabled or not supported.
  • Content is accessible and understandable when images are disabled or not supported.

Video

  • All videos hosted on YouTube have captions (subtitles) if they include spoken words.

Forms

  • All form controls and fields are properly and clearly labelled.
  • Form inputs have been assigned types and attributes so that the correct keyboard is loaded on touchscreen devices.
  • All crucial form fields are checked for errors when the form is submitted.
  • Any error found is described to the user in text, along with suggestions on how to correct the error.
  • All forms have an appropriate focus order so that they can be navigated with the Tab key on the keyboard.
  • All forms can be submitted using the “Return” or “Enter” key.

Using the proper input types and attributes, such as required and placeholder, is easy and makes the form more accessible.


<input type="email" id="email" name="email" value="" required="" placeholder="Pop your email address in here">

Just Getting Started

Since we launched our new website a couple of weeks ago, the results have been impressive. Mobile traffic has increased by over 200% (with an 82% increase on average for all traffic); the average duration of a visit is up by 18%; and the exit rate on the home page for mobile users has decreased by over 4,000%. While statistics can tell us only so much, these indicate that the responsive website is performing better on mobile than our previous separate mobile website.

According to Google Analytics, server-response times have decreased from an average of 1.21 seconds to 170 milliseconds. Similarly, page-loading times have decreased from an average of 9.19 seconds to 1.82 seconds.
According to Google Analytics, server-response times have decreased from an average of 1.21 seconds to 170 milliseconds. Similarly, page-loading times have decreased from an average of 9.19 seconds to 1.82 seconds.

The important thing to remember here is that this is just the beginning. We know we can improve in some areas: pushing performance optimization much further, reducing file sizes, being more future-friendly with touch gestures across all breakpoints, using server-side solutions such as adaptive images for further contextual enhancement, conforming more closely to the Web Content Accessibility Guidelines’ “AA” standards.

Going responsive is just the first step for our website.
Going responsive is just the first step for our website.

At 2012’s inaugural Smashing Conference, Brad Frost quoted Benjamin Franklin, who said, “When you are finished changing, you’re finished.” For anyone working in the Web industry, this statement will particularly ring true. We work in a medium that is both rapidly and constantly evolving. Keeping up to date with this ever-changing landscape is a challenge, but it’s what makes working with the Web so fantastic and exciting.

We see the launch of our new website as the first improvement of many in our quest for a truly responsive design — and we can’t wait to see where it takes us.

(al) (ea)

↑ Back to top

Matt is a designer, tea lover and zombie hunter, though not always in that order. During the day he is Production Director at Cyber-Duck, a full service digital agency based in sleepy Elstree in Hertfordshire UK, home of James Bond, Indiana Jones, Luke Skywalker and perhaps most famously Peggy Mitchell. At Cyber-Duck, Matt oversees all design work from the early research and planning stages, to sketching and designing interfaces, right through to helping deliver HTML/CSS code.

  1. 1

    Finally an article about responsive design that actually gives real, honest, no BS advice!

    0
  2. 4

    Very interesting article, we had the same way of working for gentside.com

    0
  3. 5

    Wouldn’t using a CMS with caching have gotten you “most of the way there” for reducing server queries, without the PITA factor of upkeeping a static website?

    0
    • 6

      Agreed, I was balking at that bit about removing the CMS. It’s a daring move, but I can’t help but feel that it’s going to bite you in the ass later.

      That being said, I’m working on my first Laravel project myself and I know how powerful it is. Perhaps for your staff’s skill level that itself is okay.

      0
    • 7

      That really depends on how much up keep there is compared to lag in the cms. If they are only going to update a price sheet once and a while and they know html. It would likely take the same amount of time to navigate the cms as it would to modify the content.

      0
    • 8

      It depends AC, for us at Cyber-Duck it hasn’t taken any longer to update the content using templates than using the CMS we had before. Although we know is not a solution for everyone.

      In one side, we all know html to quickly modify the content at any time, and our deployment procedure makes it easy to put live as well.

      In the other side, the templates are very easy to deal with, they don’t have anything other than the content and this also gives us the freedom to make different things with each page when we need.

      0
    • 9

      It really depends on the content, how frequently it is getting updated and who is doing the updating. In most scenarios implementing a CMS with caching would be more appropriate. Given that our own site is being managed by people who are comfortable coding, most of the content (asides from the portfolio section perhaps) only requires occasional tweaks or additions, we decided that managing/editing static views was a better trade off compared to the inevitable overhead a CMS brings (regardless of caching / optimisation). Saying that, we did keep the CMS for our blog, mainly due to the frequency and volume of content that is published there.

      0
    • 10

      Using a CMS that didn’t generate the worst SQL ever would have been a good start. There isn’t a web page in the world that requires 1,500 queries in order to display it even if the whole thing was database driven and abstracted to the nth degree. A well written CMS can build the entire page with only a couple of queries that take a few milliseconds to run, and that’s before you start caching elements or entire pages or look to NoSQL solutions if scalability (always a nice problem to have) is still an issue.

      The rest of the article has some good content but it was frustrating to see some of the choices made be based upon performance issues from a very poor CMS implementation. Don’t lose flexibility or ease of use, for the end user or the site administrators, through poor implementation.

      0
      • 11

        Chris, I completely agree that we could have gone down the road of implementing a more lightweight CMS like Perch or even optimised our use of wordpress far more to reduce the performance overhead of our CMS. As I disclosed, for most clients we would go down this route based on their site administration requirements, just with our own website we decided that we didn’t actually need a CMS for most of our content (apart from our blog).

        0
  4. 12

    I have to say database driven websites are the only way I can see delivering mass content that’s manageable and future proof. Using no CMS means a novice will never be able to edit your website in it’s current format (apart from the blog…).

    Content changes along with the design and technologies that are used. Not being able to manage the content without someone HTML literate seems a little short sighted.

    On the whole, great article though.

    0
    • 13

      Yup, it wasn’t my intention to present this as an option that will suit everyone. Thankfully we don’t have the concern of not being able to manage the content on our own site, everyone here is HTML literate.

      0
  5. 14

    This is by far one of the best examples of common sense approaches to design and development. It’s a method I support 100% and I’m glad know that others are prioritizing the work flow based on the scope of project needs verses wants. If more designers and developers wake up and minimize their use of “template and framework crack addiction” , we will all understand how to budget our bandwidth.

    There’s nothing wrong with wanting the coolest and newest but it comes down to what you truly need to get the best results and if you’re good at what you do, a framework can be bypassed at times.

    0
  6. 15

    Taking your own product as an example has helped you provide a remarkable well-structured article with very helpful advices about responsive design, thanks! Good stuff.

    0
  7. 16

    This is an informative, detaild look ininto actually overhaul a site for good efficiency and responsive design

    I like how you choose your third party coding tools with discretion to avoid a bloated site.

    0
  8. 17

    Amazing article.. Ive been going bonkers over bootstrap over the last few days and it didnt take me much time to realize i may have to remove all the unwanted styles and scripts. I am using backbone and this speeds up to a great extend. Will definitely include the uglify and image compression too.. Great article once again..Very informative.

    0
    • 18

      Hey there, I’ve got my first responsive website to do. I’m doing it in wordpress, and I thought why not try out that bootstrap? Exactly like you, I have come to the conclusion that it’s absolute overkill. All I want is some system where columns stack, and content gets smaller to fit the device width; and a menu that goes to 3 little lines when it’s a mobile device. Do you know of anything like this out there? No extra styling, just that functionality?

      0
  9. 19

    Myles Cowper-Coles

    June 18, 2013 8:38 am

    You talk removing the CMS and how that affected page load times (which i think is a great idea), but I was wondering if you know what the difference in speed would be between using an MVC structure like Rails, to using a javascript system such as Meteor against using a bunch of html/php files in a static structure. Any ideas?

    0
    • 20

      Hi Myles

      We have tried several options (Including Python and Rails) with different outcomes, like Matt said, not a single one of them was as fast as this. I have not tried Meteor yet, but I’m still not 100% comfortable by using Javascript to manage something like this, as they are not usually very accessible, maybe in the future we will try a different approach. We are not closed to try new things :)

      Another option we have consider is to create an editor to update/create our templates online, but we don’t need it for now and we are still changing and optimising…

      0
  10. 21

    “…even the most lightweight, highly optimized CMS with clever caching has overhead and cannot match the performance and server footprint of static files.”

    Yup, that about sums it up!

    0
  11. 22

    Great article, very thorough and honest, and I recognize a lot of the principles you used in my own responsive project. I have to ask though:

    ” a typical page with WordPress uses around 600 to 1,500 queries to load”

    Is this really true? I know little of WordPress so I am extremely shocked by those numbers. If they are true, surely WordPress must be a performance hog everywhere?

    By the way, that debugging output looks a lot like CodeIgniter’s output. I see that output a lot in one of my own CI projects, and I generally get worried when a page loads more than 10 queries. When I spotted 1459 there in your screenshot my mind was blown.

    0
    • 23

      600 – 1500 Queries isn’t typical at all, it’s insane. I’d consider >150 excessive. I’m not really a fan of wordpress, but I built a handfull of pages with it, including a local news portal, which is where the ~150 number came from. Including a page cache can bring down the number of queries to a handful, or none at all depending on the type of page and the amount of non-cachable / ajaxy stuff on it.

      0
    • 24

      It’s semi-true, but quite misleading. While WordPress can be a bit of a resource hog, there are plenty of caching plugins that can effectively reduce database requests to 0 by utilizing disk-based caching.

      0
    • 25

      The same here, i get worried about 5 queries… but 600 to 1500? I can’t believe it !!!

      0
    • 26

      I thought the same. I don’t use WordPress either but I’d say that figure has been misinterpreted…

      0
    • 27

      It’s no where near that much if the theme is well designed and caching plugins are thoughtfully implemented. My previous company’s website generally loads in less than 400ms on a Linode VPS configured by a non-expert. The site has over 4k pieces of content, for the record.

      0
    • 28

      Thanks! ‘typical’ can be quite subjective, I was basing this largely (though not entirely) on our old website which was a complex application loading all content from the CMS rather than say your average blog.

      The CodeIgniter output (well spotted by the way) was from our old homepage, which had everything dynamically loading via the CMS, from the navigation to portfolio items to all of the other bits of content right through to our footer, so there were indeed a lot of queries. We could have of course improved performance massively by implementing better caching and optimising the queries, but no amount of optimisation beats the performance and footprint of static files, which is why we decided this was the direction we wanted for our new website. This approach of dropping the CMS isn’t suitable for everyone, nor indeed for many of our clients, but as designers we should consider what technology we need and what is appropriate.

      0
    • 29

      Yeah that blew me away a bit too! Throughout all my themes I average about 40-50 queries to display a page. 1500 is crazy! At that amount I’m not surprised you abandoned the CMS entirely.

      But I do feel that a database based CMS (one with a more reasonable resource load, haha!) has a lot of benefits, and sacrificing that might be stifling when it comes to growth, or future redesigns. Sure everyone there knows HTML and is comfortable editing static pages… but I’ve come across so many clients who were delivered a site from another developer who didn’t consider their work within the scope of their clients’ “lifetime”, and didn’t make it extendable in the least.

      I agree with everything else though! Good work!

      0
  12. 30

    Just wondering, did you consider DataURIs and/or using some manner of LocalStorage caching? If so, what made you choose to avoid it?

    0
  13. 31

    It’s awesome!!! Thanks for sharing the responsive experience with us. Our industry is changing too fast but it’s also interesting to learn and take the challenges.

    0
  14. 32

    I think removing the CMS behind your site was a bit heavy-handed as there are many ways to serve your site as a static page while still having a CMS in place.

    For instance, you could pair APC cache up with disk-based caching. The first visit to a page is served dynamically, utilizing APC to reduce duplicate database requests. Once the page has been generated you can then output it to a static file, which is served to subsequent users.

    0
  15. 33

    Simply pairing your CMS with some sort of disk-based caching along with server-based caching such as APC you could’ve achieved the same results without having to resort to removing the CMS all together.

    0
  16. 34

    Thoughtfully written and explained without any non-sense. An approach that is clear and concise I hope to follow your example when tackling redesign myself. Well done sir.

    0
  17. 35

    Bambi Corro III

    June 18, 2013 7:32 pm

    I have a question which I guess SmashingMagazine should write an article about, or I didn’t bump into it yet. How much should we charge our clients if they want to have an Adaptive website? Should we charge them 3x because we created at least 3 different websites for them – Desktop, Tablet and Mobile? Or should we consider it as an added-value?

    0
    • 36

      From our experiences producing a responsive site ≠ 3 different websites. Saying that, QA testing a responsive website does involve more work and time so we do factor that into our pricing.

      0
  18. 37

    This article was a great read. I’m currently in the process of rebuilding my site. Coming from a site on a WordPress blog moving to a flat-file site, just the couple of pages that I have done I noticed that things load much faster. I moved away from a CMS becasue I really just want something small, and it is only myself publishing content.

    Will be interesting to see how my little site can benefit from a few of these suggested changes.
    I’ve only got 2 months to do this as I want it up and running so I can be updating it live over the 3 weeks I’m on holiday in the USA and New Zealand this year.

    0
  19. 39

    Yes! I have been avoiding using CMS and tried to stay away from CSS engines and JS plugins as much as possible for the past four years. I kind of had to keep it to myself because my decisions were not very popular considering the excitement and ease of use those tools bring. But I am glad you guys mention it here and hopefully it will pave the way towards avoiding overusing those tools. Otherwise its like using chainsaws to make toothpicks.

    0
    • 40

      “its like using chainsaws to make toothpicks” Exactly. If all you have is a hammer, then everything will begin to look like a nail. I’m not saying what we did for our own website (CMS-wise) would be suitable for every project, but the point is keeping an open-mind and exploring different options and picking the best tools for the job.

      0
    • 41

      I agree with you somewhat. That there are applications where a full-blown CMS is a little overkill, or some libraries or bootstraps are just too much – but remember we are creating products for our clients. Sometimes these things add a layer of usability – especially for the less than savvy – that can outweigh the extra overhead.

      Now this is just me, but if I deliver a site that my client can’t update, can’t extend, and can’t have me update or extend cost-effectively because I gave them an end product that suited my own ideologies rather than their needs, I have failed.

      0
  20. 42

    Great article, I will follow these advices in my next project.

    0
  21. 43

    Kinda lame that this article gives code example’s that clearly won’t work. For example the below code, it’s not possible to animate to height: auto; with css

    .menu {
    height: auto;
    transition: height 200ms linear;
    }
    .menu.closed {
    height: 0;
    transition: height 200ms linear;
    }

    0
  22. 47

    Great article! Gave me something to think about, my blog page performance is awful and with plasters all over it caching content it still isn’t cutting it. Your site on the other hand is very fast and especially like the transitions, not sure i can spare the time to build from scratch for my blog but definitely something to look at for next commercial site I work on.

    0
  23. 48

    Thank you soo much. Your idea of removing like buttons and other social buttons just boosted my website.

    0
  24. 49

    Great article! I went through the same stuff with my company’s website, minus the responsive design (just all the optimization stuff). I ended up doing it all manually instead of using other JavaScript libraries like RequireJS to do the work. Just thought they added too much overhead, plus there weren’t many good ones around three years ago when I did it. Your site looks great…keep up the good work.

    0
  25. 50

    Quite possibly the best RWD article/case study I’ve ever read. Brilliant stuff!

    0
  26. 51

    Thank GAWD someone is actually talking about removing a CMS.

    My business mainly involves troubleshooting software for clients and I cannot begin to describe how frustrating it is to constantly deal with poor CMS implementations in situations where there was absolutely no need to use a CMS.

    Really good article as well!

    0
  27. 52

    Great article. I was a bit unclear about something, when you said: “For the slideshow banner on the home page, we optimized for different screen sizes by using media queries to ensure that only appropriate-sized images are loaded.”

    Wouldn’t this approach still download all the slideshow assets and image sizes on all devices? I was under the impression that all CSS images are still downloaded, despite being inside a media query?

    0
  28. 54

    This was an awesome article.

    0
  29. 55

    Wonderful article! Great exercise in research and performance. One of the better factual write ups instead of those based on theory or small tests to use as examples.

    Personally, I like the idea of dropping the CMS. If you can do it, you can reap some rewards like you have shown.

    0
  30. 56

    Excellent article guys.

    I’ve been looking for some answers on whether or not to steer my company in the direction of a responsive website or a completely separate mobile website…

    Most other articles just leave things open ended leaving you in the exact same spot as before you read it. That’s not the case with this one and you’ve provided me with some great things to consider.

    Thanks!

    0
  31. 57

    > WordPress uses around 600 to 1,500 queries to load.

    Seriously? I can now brush aside your post as amatuer in all regards. A well coded and optimized WordPress does no more than 10-15 DB queries on page load. I can usually get it down to 5, not 1500 LOL. The load time of that being in the 0.000 range of milliseconds.

    Furthermore:

    Loading images is almost always the single greatest load barrier, you can only do this effectively on the server not with CSS.

    Several of you animation paint times go below 30FPS not exactly speedy.

    Having to edit text content and images manually like it’s 2002, ridiculous.

    0
  32. 58

    Loved this article! This is why I keep coming back to Smashing Magazine. This is exactly the type of case study I enjoy: from the horse’s mouth and with clear explanations as to the choices made.

    I am very curious to know if you’ve noticed an increase in conversion rates, though? Are you getting more calls, more emails, or more messages through your forms? Also, do your existing clients have anything to say about the revamp?

    Thank you Matt for taking the time to put this together. While I wouldn’t have necessarily made all the same choices at the web development company I work for, it was a real pleasure to read and gave me things to chew on.

    0
    • 59

      Thanks Tom, glad that you could take something away from it, even though you wouldn’t necessarily make the same decisions as we did.

      Though we have noticed an increase in total conversions + % rate, it is difficult to pinpoint as there are many variables which can impact this. What’s more important to us than quantity is quality and this is probably what we’ve been most happy with since re-launch.

      0
  33. 61

    Brilliant article and some excellent advice to take forward when either considering a redesign or creating a new website.

    Definitely going to return to this article for tips on my next project.

    0
  34. 62

    I found this article very usefull and I agree with all the facts written in it, and most of them are on the same path with my recent toughts about optimizing for mobile.
    But I disagree with the way it was presented, because it’s very misleading. Let me explain why I think it’s misleading…

    I talked with my designer yesterday and he told me about this article, and the first thing he said is “they removed the CMS in order to optimize for mobile!”. And that was a “revelation” to him and the key point of our further discussion – which in my opinion should have never happen and we should have concentrated on other parts of your article.
    Is that really the first impression that you wanted people to have?

    You have put the slowliness of the CMS as the first point, and the main factor in mobile optimization. You even wrote that “our previous CMS was a key factor in the slow page-loading times”, while instead you should have written that you didn’t know how to optimize a CMS, or didn’t want to loose your time with it.
    Any CMS that cannot avoid producing 1.500 queries for a page load should not be used or even called a CMS. Every decent CMS today has caching mechanisms that reduces the number of queries to 1-10 queries per page load (and some of them even to zero).

    I agree that there’s no CMS that can serve the pages as fast as serving static files, but the difference (if the CMS caching is done porpperly) is minimal and it can be at max 50 miliseconds which is less then 1% of page load time.
    I am not saying this out of nowhere, I have done a benchmarking (with 60 concurrent requests) on your site, and on one of my sites (which uses a very complex CMS with lots of content), and the average response time in both cases was the same – 0.19 seconds.

    Furthermore, if you are using CloudFlare for CDN and want to optimize your site as much as possible, why didn’t you use CloudFlare’s content caching mechanism (that’s available even in the free plan)?
    If you have done that, then it wouldn’t make any difference whether the response time of your CMS is 1, 2, or 5 seconds, because all the content would have been delivered from CloudFlare cache.

    Bottom line, CMS removal is NOT the key factor in optimization for mobile. I understand that you also had other reason for removing it but in general this is not a decision that should be made under mobile optimization topic.

    The main part of optimization for mobile is on frontend, and this is what people should be focused on, and not on decisions whether to use a CMS or not. The way you wrote this article leads people away form the important things. I can bet that a lot (of course, not all) of people that read this article are now thinking about the “removing CMS” part, and not about the rest of the article which is (in my opinion) far more important.
    For example, look at the comments on your article, most of them are about the “removing CMS” part, and there’s almost no talking about the frontend part.

    Yes, you did state that removing the CMS is not a choice for all the projects (and repeated that in the comments), but that’s not the point. Try to read this article once again and imagine what impression does it leave to a designer with no developer’s knowledge when you begin with the headline “DID WE REALLY NEED A CMS?”, and then continue with misleading figures of 1.500 queries per page load…

    So to sum it up, there are very usefful things in your article (althoug I wonder why didn’t you touch the topic of SVG), but in general is misleading and should have been written differently.
    Besides that, great work :)

    DISCLAIMER: Yes, I am (by nature) a developer and not a designer, but now I have mostly moved into the team leadership, and lately I do very little coding and mostly planing and decision making. Therefore, I’m not writing all this only from a developer’s point of view, but from a point of view of person that has to make strategic decisions.

    0
    • 63

      Thanks for your detailed and thoughtful response. To answer your questions:

      “Is that really the first impression that you wanted people to have?”
      My intention was to explain what we did on our responsive website and why we made certain decisions, which hopefully would help some people starting responsive projects now. Whilst of course some people have focused on the CMS aspect, I don’t feel like this was the focus of the article, just a small part of what we did during our responsive design.

      Like you say, I did disclose in the article and in my comments that this is an option that this approach is certainly not suitable for all projects. Though I did mention other solutions such as improving WP optimisation / caching, using file-based CMS’ or building/customising something a more lightweight CMS, perhaps I could have explored this more in the article. Saying that, I do want people to question what technology they’re using and if it is the best technology to achieve what they want (hence the title: Did we really need a CMS?).

      However, I don’t believe showing our stats from our old website is misleading, though as we can see from the comments saying *typical* was too subjective. We’re not the first and certainly won’t be the last to have such experiences with WP, though perhaps I could have covered a little more about WP optimisation (for our blog where we’ve kept WP, we did make some big improvements as you can see).

      “Furthermore, if you are using CloudFlare for CDN and want to optimize your site as much as possible, why didn’t you use CloudFlare’s content caching mechanism (that’s available even in the free plan)?”
      Our static subdomain uses CloudFlare to cache the assets such as images, javascript, css, we didn’t feel the need to cache the content, though this is something we may look into in the future.

      “I wonder why didn’t you touch the topic of SVG”
      Good point, this was merely because we didn’t use SVG during this initial build, though it’s something we’re looking into implementing as a future improvement.

      “Besides that, great work :)”
      Thanks! :)

      0
  35. 64

    Great article and in-depth overview of a difficult process.

    In defence of wordpress, the average, non query-optimized page still stays under 40-50 queries, in my experience. Ok, nightmarely written plugins could double the number easily i suppose. (so i could stand to read 60-150 queries).
    But HEY, it’s really unfair to say that “a typical page with WordPress uses around 600 to 1,500 queries to load” ; not true and unfair to all wordpress community.
    I suppose no one would use a CMS that needs 1500 queries to output a page, when he can simply write the same page in a static way.

    0
  36. 65

    Great read, very helpful

    0
  37. 66

    Andrea D'Ippolito

    June 24, 2013 7:14 am

    I’ve really learned a lot with this article, thanks!

    0
  38. 67

    Great piece. Lots of good advice, tips and specific scripts.
    Appreciate you taking the time to do this.

    0
  39. 68

    Nice article and surely inspiring. But I would like to question few points.

    Why do you change classes via Javascript to serve different devices a different layout, when you could simply use media queries? I would JS to change classes mainly to serve devices that do run Javascript, or perhaps for animations. Not for styling.

    Your grid system is based on floating elements which sounds obsolete at this point in RWD. Have you tried a “Justifying” approach? ( http://www.barrelny.com/blog/text-align-justify-and-rwd/ )

    The entire breakpoints system is based on pixels. Why not ems?

    To reduce impact on mobile caused by Social Media plugins, do I understand correctly that you simply removed them entirely from the website for any device? Wouldn’t have been better to selectively load them on Desktop?

    There is lot that I appreciate in your articles, but the few points above made me wonder if you could actually do more.

    Thanks for sharing, keep going with the good work ;)

    0
    • 69

      Hi Carlo, I’m front end developer at Cyber-Duck, here’s some answers to your questions, I hope is not too late…

      If you check carefully, we don’t change classes to show different layouts based on screen size, we are using JS to to add classes that reflect the “state” of an element, everything else is managed via CSS and media queries.

      Regarding the floated elements, I don’t believe is fair to say that floated elements is obsolete, the justify technique is different, but not necessarily better or worse, and it has its drawbacks. We just decided to use what we know it works best for our layout.

      On ems vs pixels, this is something I’d like to change in the near future, but since we had to meet certain requirements on the design aspect, we decided to use pixels to ensure it would look as expected in all situations. Eventually we most probably will change this to ems.

      The social media plugins, we decided they were not helping us enough to justify their existence, that’s why we removed them across all breakpoints.

      Beyond all that, we know we can still do more, there are many improvements we want to apply next, and new things come up everyday that will help us plan for future improvements.

      0
  40. 70

    You applied Responsive Design methods in a very Clever way, That’s why You get good results. Most of the people don’t consider Optimization techniques. They Just design the websites & Publish.

    0
  41. 71

    Great article. Just one question, can you let me know (generally) how long the whole process took from initial ideas to release? For example, did it take weeks, months? Thanks!

    0
    • 72

      Hi Craig, I’m sorry took so long to see this.

      The whole process took a few months, because we started from scratch, redefining everything we had. It was a long ride but totally worth it.

      0
  42. 73

    awesome article guys, there’s been a lot of thought put into this, definitely will be coming back to this article to incorporate your ideas into my own sites

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top