Granola: a WordPress starter theme built for efficiency and performance

A few years ago, the team here at Wholegrain Digital developed a modular starter theme for WordPress called Nuts. It was an interesting project and a lot was learned, but after 2 years of development it was decided that it simply did not meet the needs of the agency or our clients.

When I joined Wholegrain Digital in 2017, we made the decision to start development of another theme to build our websites from. It was controversial not just because of previous sunk costs, but because the opinions within the team were split over whether it was necessary and what it should include.

There are plenty of other WordPress starter themes out there, so the huge investment in developing a new one would need to be justified with clear benefits and a strong commitment to see it through to success.

In this post I’m going to talk about why we decided to embark on developing a new starter theme called Granola, the structure of Granola, and what we have achieved 18 months on.

Where to begin?

At Wholegrain Digital, we have a mission “to create the best websites in the world, use our business as a force for good, and help to accelerate the shift to an Internet that’s good for people and planet”. Like most mission statements though, it doesn’t explain how we go about doing it, or why. With that in mind, let’s discuss a little about the work we do.

Carbon emissions produced by the internet are rising every year, and there’s no signs of it slowing. Currently, the internet produces 2% of global carbon emissions, about the same as Germany. With the advent of streaming services, the amount of data transferred has grown exponentially, and the carbon emissions with it. Whilst it can be daunting to know where to begin, we started with what we could do in our own work.

“You can’t manage what you can’t measure – Peter Drucker”

Peter could not have put it better, so in 2017 we launched the world’s first Website Carbon Calculator. By providing a URL, Website Carbon gave us, and the internet, a way to measure the carbon emissions of websites. With the ability to monitor finally in hand, we began to manage the emissions of our own websites with objectivity.

The needs of the many

But, carbon emission reduction is only one piece of the puzzle, and one that is rarely at the forefront of the clients’ mind when preparing a brief and selecting a partner. We need to create performant, secure, accessible, and efficient websites to meet the needs of our clients.

When it comes to building websites, and where we start the development process from, we didn’t want to start from scratch each time, but we also didn’t want to remove code each time we started a new project. Ultimately, we defined our requirements as an efficient, flexible, minimal but powerful starter theme that delivers on performance, security, accessibility, and efficiency, as well as improving development experience.

At the time, and to this day, we program our sites in HTML, SCSS, Javascript, and PHP. What we needed in Granola to achieve our objectives was:

  • WordPress templates and partials for common patterns with minimal HTML
  • Source files written in SCSS and Javascript that don’t need to be removed at the start of each project
  • Powerful and extensible tooling for compiling and optimising assets in development and production environments
  • Helper functions for working with assets and files
  • Integrations with our most widely used plugins for WordPress (Specifically Advanced Custom Fields, Gravity Forms, and Yoast SEO)

What about the competition?

Before embarking on the 18 month and counting process in developing Granola, we spent time reviewing and testing other WordPress starter themes. Whilst every starter theme approaches the solution differently, what we found was none were quite what we were after.

We wanted a starter theme that worked across all aspects of the code base, from a folder structure for laying out code, to source files and build tools that allow us to code in modern code and have it work in our supported browsers, to optimisations for assets and WordPress that make the site as accessible and performant as possible. In short, we wanted it all (but without the bloat).

A quick search for WordPress starter themes returns a long list of projects. The big names are Underscores, Foundation Press, Bones and Sage. Underscores is a logical choice if you want solid HTML and CSS. For us, it had too much boilerplate code and not enough of everything else we were after. Foundation Press is a one stop shop for all the front end components needed to make a website, but in doing so it also includes all the things that you don’t need too. Sage came close; it has a structured, well documented code base and a community surrounding it, but we wanted to stick closer to native WordPress and PHP rather than the WordPress code behind an MVC architecture and templating languages.

Not content with what was available, and not scared of the short and long term investment of building and supporting an open source project, we began the work of building a starter theme that was designed and optimised for us and our clients. Our objectives, our workflow.

Introducing Granola – our high performance starter theme for WordPress

Granola is a WordPress starter theme with a modern workflow, modular structure, and high standards. Employing modern approaches to the age old job of WordPress theme development, we are able to produce more reliable, tested and efficient code and assets. To best understand Granola and its structure, it is best thought of in four core tenets:

Source files:

  1. styles (SCSS)
  2. scripts (ES6+ javascript)
  3. images (jpg, png, svg, etc)
  4. font files

Tooling

  1. Converting source files to web languages understood by a browser
  2. Build tools for development
    1. Source maps
    2. Live reloading
    3. Linting
  3. Build tools for production
    1. Minification of code and files
    2. Tree-shaking
    3. Cache busting
    4. Generated POT file with strings ready for translation

Frontend code

  1. WordPress partials implementing landmark accessible HTML
  2. Commonly used components (burger, skip link)

Framework

  1. A configuration file for configuring WordPress requirements for the theme
  2. Tools for working with assets generated by tooling
  3. Optimisations for WordPress and plugins
  4. Abstractions for WordPress consolidating different methods of retrieving content, thus simplifying the development process

Words only go so far though, and there’s quite a bit to digest. The easiest way is almost certainly with a picture, or if you are interested in seeing, or using it for yourself, visit the Granola git repository.

Structure of the Granola code base

Granola is opinionated

Granola is opinionated – but we think that’s a good thing! Granola has a folder for nearly every aspect of the code base, and when it comes to writing code, Granola lints your code to make sure its inline with the higher standards it aspires to.

Whilst talking about those higher standards, Granola embraces the open source community, and aspires to widely held industry standards. Regarding PHP, Granola lints with and is compliant with PSR2. For Javascript, it lints with and is compliant with eslint recommended standards, and for SCSS, it lints with stylelint and validates against the SCSS guidelines and Idiomatic CSS. Whilst in places these standards conflict with the WordPress coding standards, we chose to prioritise higher standards than default to the WordPress codex.

The tooling inside Granola is a combination of the Javascript community, the PHP community, and some homegrown pieces pulling it all together. We employ Node, NPM, Gulp, BrowserSync, Babel, Webpack, eslint, PostCSS, SCSS, Autoprefixer, stylelint, and a host of other packages for building development and production assets. On the PHP front, we have Composer for managing dependencies, and Codesniffer for validating our code against PSR2 and PSR4. At its core though, the tooling has just a few objectives:

  • Produce tested, reliable code
  • Improve the developer experience
  • Make assets and code as efficient as possible

What Granola doesn’t do is force libraries upon you. If you would like to use Foundation, Bootstrap, or a flavour of atomic css, go for it! Whilst SCSS functions and mixins are included, they don’t provide any bloat to the final output. Have a favourite templating language you like writing in? Granola can support that too. By providing hooks in to the core functionality that Granola brings, it’s possible to change, add and remove parts you want or don’t want.

How has it performed?

Granola has been in use at Wholegrain since mid 2017, and through that time it has changed its tooling and implementation. But what hasn’t changed is the mission.

This year, we have launched several projects built on top of Granola, and each achieved the high performance and efficiency standards we hold pivotal to our websites. Not all of the success can be attributed to Granola, a great team and great design are at the heart of everything we do, but having Granola means the mundane is taken care of and leaves us to focus on making what we can even better.

A few examples of recent websites built on Granola are IFEX, Nu-Heat, Thameslink Programme and  Red-Inc.

ifex, by Wholegrain Digital. Build with Granola

Going forward

Granola is and will continue to evolve. On the technical front, we recently migrated from Webpack 3 to Webpack 4, and Gulp 3 to Gulp 4, resulting in a smoother developer experience and more efficient code. For the end users, we have implemented service works and the requirements for Progressive Web Apps, giving users a faster experience between pages, speedier page loading and even access when they are offline

WordPress is only what it is because of the community. We, and so many others, have built our businesses on the back of WordPress and its community. As such, we believe we should find ways to give back to the community that has given us so much. Granola is, and will continue to be, open source. But Granola is also supported by the team at Wholegrain Digital. We would love for all to try it out.

Build your next great project, submit a pull request to help it evolve, have a discussion with the team working on it. Whatever it is, we’re up discussing it!

Get our latest articles about a positive web straight to your inbox

We promise no spam, just good content