Menu Search
Jump to the content X X
Smashing Conf New York

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Adapting To A Responsive Design (Case Study)

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-Duck1, 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 parity2 for users and a single website to maintain.

Why Adapt To A Responsive Design? Link

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 websites3
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 Mobile4 to enhance the user experience with touch gestures.

Changing Our Approach Link

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 “phablets5.”

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.6
We wanted our new website to be easier to maintain and more future-friendly7 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 Link

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 Analytics8, Lead Forensics9 and CrazyEgg10 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 website11
Our design team used card-sorting exercises to reorganize our existing content for the new website.

Making Performance A Priority Link

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 Link

The easiest way to trim the fat was to strip down third-party scripts as much as possible. According to Zurb12, “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? Link

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 Relic13, 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 seconds14
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.15
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. 16
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 Kirby17 and Statamic18, building or customizing a lightweight CMS such as Perch19, or simply implementing better server-side caching such as with Varnish20.

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 Link

While CSS frameworks such as Twitter Bootstrap21 and Foundation22 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.23
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 Sass24 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 GitHub25 (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 Link

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 RequireJS26 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 UglifyJS27 to reduce the file size of the JavaScript.

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

Optimizing Image Assets Link

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 options29. 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.30
By desaturating and blurring parts of images that are not essential, we significantly reduced image sizes.

We also used ImageOptim31 and TinyPNG32 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 Link

Yahoo’s golden rule of performance33 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 network34 (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 Link

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 Link

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.35
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 Link

For the animated slideshow of our projects on the home page, we used SequenceJS36, 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 Link

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.37
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.38
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 Link

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 Link

  • 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.
  • 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 Link

  • 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 Link

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

Forms Link

  • 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 Link

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.39
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 images40 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.41
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)

Footnotes Link

  1. 1 http://www.cyber-duck.co.uk
  2. 2 http://bradfrostweb.com/blog/mobile/content-parity/
  3. 3 https://www.smashingmagazine.com/wp-content/uploads/2013/04/1-old-duck-websites-large.jpg
  4. 4 http://jquerymobile.com/
  5. 5 http://en.wikipedia.org/wiki/Phablet
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2013/04/14-device-explosion-large.jpg
  7. 7 http://futurefriend.ly/
  8. 8 http://www.google.co.uk/analytics/
  9. 9 http://www.leadforensics.com/
  10. 10 http://www.crazyegg.com/
  11. 11 https://www.smashingmagazine.com/wp-content/uploads/2013/04/3-card-sorting-large.jpg
  12. 12 http://www.zurb.com/article/883/small-painful-buttons-why-social-media-bu
  13. 13 http://newrelic.com/
  14. 14 https://www.smashingmagazine.com/wp-content/uploads/2013/04/5-wordpress-db-queries-large.jpg
  15. 15 https://www.smashingmagazine.com/wp-content/uploads/2013/04/6-designing-performance-large.jpg
  16. 16 https://www.smashingmagazine.com/wp-content/uploads/2013/04/7-laravel-profiler-large.jpg
  17. 17 http://getkirby.com/
  18. 18 http://statamic.com/
  19. 19 http://grabaperch.com/
  20. 20 https://www.varnish-cache.org/
  21. 21 http://twitter.github.com/bootstrap/
  22. 22 http://foundation.zurb.com/
  23. 23 https://www.smashingmagazine.com/wp-content/uploads/2013/04/8-responsive-grid.jpg
  24. 24 http://sass-lang.com/
  25. 25 https://github.com/Cyber-Duck/hoisin.scss
  26. 26 http://requirejs.org/
  27. 27 https://github.com/mishoo/UglifyJS
  28. 28 https://www.smashingmagazine.com/wp-content/uploads/2013/04/9-scripts-optimisation-large.jpg
  29. 29 http://help.adobe.com/en_US/fireworks/cs/using/WS3f28b00cc50711d9-73dfa65f133a490f3b9-8000.html
  30. 30 https://www.smashingmagazine.com/wp-content/uploads/2013/04/10-image-compression-large.jpg
  31. 31 http://imageoptim.com/
  32. 32 http://tinypng.org/
  33. 33 http://developer.yahoo.com/performance/rules.html
  34. 34 http://www.cloudflare.com/features-cdn
  35. 35 https://www.smashingmagazine.com/wp-content/uploads/2013/04/11-responsive-navigation-pattern-large.jpg
  36. 36 http://www.sequencejs.com/
  37. 37 https://www.smashingmagazine.com/wp-content/uploads/2013/04/15-flexible-grid-large.jpg
  38. 38 https://www.smashingmagazine.com/wp-content/uploads/2013/04/12-device-testing-large.jpg
  39. 39 https://www.smashingmagazine.com/wp-content/uploads/2013/04/16-ga-speed-statistics-large.jpg
  40. 40 http://adaptive-images.com/
  41. 41 https://www.smashingmagazine.com/wp-content/uploads/2013/04/17-rwd-result-large.jpg
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

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!

    1
  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

      Ramon Lapenta

      June 18, 2013 10:35 am

      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

      Matt Gibson

      June 18, 2013 2:34 pm

      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

      Chris Mellish

      June 19, 2013 1:01 am

      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

        Matt Gibson

        June 19, 2013 3:28 am

        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

    Jack Davenport

    June 18, 2013 7:58 am

    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

      Matt Gibson

      June 19, 2013 3:41 am

      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

    Catalin Berta

    June 18, 2013 8:02 am

    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

      Ramon Lapenta

      June 19, 2013 4:01 am

      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

      Evan Jacobs

      June 18, 2013 7:36 pm

      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

      Shawn Wernig

      June 19, 2013 8:54 am

      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

    Lenny Peters

    June 18, 2013 5:51 pm

    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

      Matt Gibson

      June 19, 2013 3:20 am

      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

    Derek McDonald

    June 18, 2013 10:43 pm

    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

      Matt Gibson

      June 19, 2013 3:53 am

      “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

      Shawn Wernig

      June 19, 2013 9:05 am

      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

    Sergi Beltran

    June 19, 2013 12:03 am

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

    0

↑ Back to top