Posted on:

At UI Farm we’ve recently completed the first phase of our responsive framework for WordPress, releasing it as our approach for clients and our own website. This article we will begin to explain some of the best features that we have already implemented. And sure, with our roadmap we look forward to add new features, improving the existing implementation whilst keeping it the most performant we can.

Scope of Our Custom-built Framework

From the very beginning, we aimed to:

  1. have a starting point for any responsive web project
  2. be able to fire up a new WordPress website in minutes
  3. have a platform that is able to easily adapt to clients’ needs
  4. have a fluid and fully semantic grid handled with custom SASS/Compass functions
  5. have web typography
  6. have feature detecting
  7. have progressive enhancement
  8. have the fewest possible WordPress plugins
  9. have everything under source control
  10. work with 3 different development environments: local, preview, production
  11. have every stage constantly documented
  12. have a straightforward CMS update plan
  13. address accessibility
  14. address hi-res monitors

To do such a thing we needed to look at performance as a major feature implemented by default from scratch, and not treated as an afterthought.

Most points respond to our need to achieve the best performance and to serve a good multi-device experience at the same time.

The majority of tasks related to the CMS and the source code are not of any interest here, since they’re related to scalability and maintenance. Let’s start with one of the most frequently debated questions.

Why Didn’t UI Farm Choose an Existing Framework?

There are plenty of ready-to-use and responsive frameworks, like Twitter Bootstrap, or Foundation. While there are many good reasons to use one of them, there are also good reasons to not use them. The context is all and our decision was based out of our specific situation:

  • we didn’t want a starting point with a pre-defined look & feel
  • we didn’t want to spend valuable time to “reset” that look & feel for each single website
  • If we had to spend a lot of time digging a framework to learn everything that’s under its hood, why not spend that time building our own based on our needs?
  • if we didn’t spend that time digging the framework, we would end up with websites full of useless non-optimised clutter

This simple analysis lead us to the decision: if we wanted something really optimised, performant and easy to scale and maintain, we couldn’t use any of the existing frameworks.

If you prefer a stronger point of view, read this analysis from Joshua Gross.

Designing the Performance

Have a Starting Point for Any Responsive Web Project

Within our framework we have two themes: a parent and a child. The parent theme is part of the framework itself, along with the CMS and our custom made functions and plugins. It has its own repository, with independent version tags and roadmap. It’s imported — and updated — in each project through an SVN external request.

The parent theme is unstyled, and it contains almost all the functions and SASS mixins to calculate and handle things like the main fluid grid, photo gallery grids, icons library and everything that’s not strictly related to the final skin of the website.

Alas, the child theme is the skin, and it’s got all the styled elements: logos, navigation menus, colours, custom web fonts, sprite image, etc.

Fire Up the CMS!

With this structure we can build a new website in minutes: create the remote code repository, set the SVN externals with the latest version of WordPress, a few plugins we use and the parent theme. We setup the database, run the 30 second setup for the CMS and finally login. We have a fully working local environment literally in minutes. Later we can think about the preview, stage or production environments (which are already set in the wp-config.php file).

Having the environment up and running, we can copy our child theme, enable it from the Dashboard and start working on the skin.

Only Few Plugins

Why? Again, to provide the best performance. The more plugins we use, the more cluttered code we have — especially since plugins tend to inject code or scripts and they’re not always fully documented. Plus, we don’t want to spend all the time needed to dig plugins, so the solution is to use no more than a couple of those and add more functionalities hacking the powerful functions.php file in the theme’s root.

Fluid AND Fully Semantic Grid

If you do Responsive Design, you use a fluid grid. But what about all those grids out there, ready to use? Well, roughly 90% of the existing grid systems rely on a heavy use of divs and non-semantic classes.

We used the power of SASS and Compass to build our own fluid grid. Relying on dynamic functions instead of fixed divs and classes, we managed to calculate all the widths and elastic gutters, on the fly, without adding any un-semantic value to the markup and keeping our tag structure clean.

Performance Specific Tasks

A vast majority of the user response time — around 85% — is spent on downloading all the components in the page: stylesheets, scripts, images. Reducing the number of components reduces the number of HTTP requests required to render the page. This is the key to faster pages. Other than simplify the pages, there are other ways to get a low number of HTTP requests.

We addressed all of these tasks specific to performance:

  1. HTTP requests to a minimum
  2. Combined and minified code assets — We set our Compass configuration to output a clean single CSS file. For both screen (including any responsive breakpoints) and print. We also minify CSS and JavaScripts.
  3. CSS at the top
  4. JavaScript at the bottom — Scripts block parallel downloads and while they’re downloading, the browser won’t start any other downloads
  5. CSS sprites — We combine all the suitable images in a single CSS sprite using the background-position property to display the desired image segment
  6. Inline images — On occasions, we use inline images, using the data:URL scheme, usually to implement gradients or fallbacks for IE8 due to the lack of support for CSS3
  7. Use web fonts for icons, instead of images. We subset the fonts, embedding only symbols actually used, to keep the size lighter
  8. External CSS and JavaScript
  9. Reduce the number of DOM elements — Another reason to avoid using divs and classes to set up a fluid grid
  10. Use a CDN

To learn more about this, there is a well done document on Yahoo’s Developer Network.

Detect and Enhance

We use feature detection for progressive enhancement, to serve specific functionalities only when supported by browser/device. Currently we’re not using any server-side device detection, and prefer to rely on finding what the device can actually do, no matter the agent.

Web Typography

We don’t set any custom web font in the parent main theme, so we’re free to decide and set it up later in our child theme. Also, if there’s no need for custom web typography we can use one of the old web-safe fonts. The less HTTP requests, the better, especially if requests are without any real use.

Oi, the Default WordPress Theme is Responsive!

Yes, Twenty Twelve theme is by default responsive, so why didn’t UI Farm use it as a parent theme and build a child theme on top of it for each client? Two reasons:

  1. Did we mention we don’t want to waste lot of valuable time on learning something pre-built?
  2. A common website built on top of Twenty Twelve has around 500 DOM elements, while our finished framework (two themes) is settled at 168.

What’s Next?

Stay tuned for the next part in the series on our Responsive Framework:

  1. Performance
  2. Design in the browser
  3. On-demand content
  4. UI Farm’s Responsive Workflow

Get in contact.