Over the past six months, I’ve become increasingly interested in the topic of web sustainability. The carbon footprint of the Internet was not something I used to give much thought to, which is surprising considering my interest in environmental issues and the fact that my profession is web-based.
The web in a warming world
As a brief recap, I attended MozFest in London last year. In between sessions I was scanning a noticeboard to see what was coming up, and I spotted a session entitled “Building a Planet-Friendly Web”. I felt a little dumbstruck. What on Earth was this going to be about?
I attended the session, and the scales fell from my eyes. In what now seems obvious but at the time was a revelation, I learnt of the colossal energy demand of the Internet. That this demand makes it the largest coal-fired machine on Earth, meaning that its CO₂ emissions are probably at least equivalent to global air travel. More and more people are coming online, but this coupled with the rise of ever more obese websites means that the Internet’s energy demands are growing exponentially. Every additional byte transferred means more energy, which in most countries means more CO₂.
It is widely accepted that we should avoid printing emails to save trees, but this leads to a false assumption that the web is a green medium. I’m afraid to say, it is not.
The good news is, it needn’t be this way. Since 2009, Greenpeace have been auditing Internet companies on their energy usage, and lobbying them to improve by way of their Clicking Clean campaign. The Green Web Foundation has an ever-growing database of hosting companies who use renewable energy, or are at least committed to being carbon neutral. And new tools are emerging to help those working on the web measure the environmental impact of our products.
There are also some great resources out there such as Tim Frick’s Designing for Sustainability, three year’s worth of talks from the SustainableUX conference, and peripheral material that while not explicitly focused on sustainability, can help us build lower carbon websites.
Enter Susty WP
I decided to challenge myself to see how efficiently I could package a WordPress website. While I was at it I thought, why not make the website about sustainability and WordPress? I know, WordPress/sustainability inception. Cool, huh?
And so, sustywp.com is born. With its accompanying theme, Susty. I’m rather chuffed to say I managed to get the load of the homepage down to 7KB of data transfer. I did actually get it down to 6, but the meta stuff added by Yoast bumped it up almost a whole KB! 😛 However, given I’m trying to spread a message, I deemed this to be an acceptable trade-off.
Before I get into the nuts and bolts, I just want to share a few headline facts:
- sustywp.com scores 100/100 on performance via Google’s Lighthouse.
- It gets straight As on webpagetest.org.
- Further to that, it devastates most benchmarks, with an average time to first byte (TTFB) of about 0.15s, and fully rendered within 0.5s.
- It’s hosted in a data centre which is 100% powered by renewable energy.
So how does it work?
Note: From this point on, this post gets a little technical. If you’ve come upon it and aren’t a web developer/software engineer type, feel free to skip to the conclusion.
The remarkable thing about this is actually how mundane it is. Heavily inspired by Heydon Pickering’s evangelising about writing less damn code, and projects like Brad Frost’s Death to Bullshit, I embarked on a root and branch pruning of Underscores, removing everything I possibly could. And to be clear, it’s not as though Underscores is full of cruft. It’s a very lean starting point for building a theme. I’m a great admirer of it and thoroughly endorse its use. However it includes certain assumptions that didn’t chime with my spartan goal of making the smallest possible WordPress site. Such as, you ask?
Nav? No. Sidebar? Get rid of it. Classes? Not in my socialist utopia.
Given the constraints I had set, anything making it to the DOM had to have a very good reason to be there. With this being an experiment, I took the somewhat radical approach of relegating the navigation to its own page. This is wonderfully liberating and means I didn’t have to go through the almost always disappointing dance of wondering how I would make it look presentable, hide it for the many users who won’t care, make sure it’s robust enough to be infinitely long with never-ending dropdowns etc.
As for the sidebar? Well I’ve always had an aversion to sidebars, so that was an easy thing to remove. Susty has no widget area. I’m sure it’ll get over it.
Is there more fat we can trim? Well, if we’re going to have hardly any HTML, and we want minimal CSS, do we really need all those classes? I wanted to try my hand at writing CSS in the way it was intended to be used, instead of bowing to the classitis and divitis that pervade the industry.
You might not need web fonts
Custom web fonts are also a potential antipattern for our users, for whom:
- Page loads are slowed down as they see either a flash of unstyled text or, potentially even worse, no text while the font loads.
- By the time the font has loaded, they don’t notice or care.
Almost every device these days has a half-decent set of fonts installed, so why not compose a stack of potential fonts you’d like to see, ending with either
I wanted Susty to have a bit of a Swiss Style aesthetic, so my font stack ranges from the perfectly proportioned Helvetica (which all Apple devices have by default) to sans-serif, by way of Arial, Frutiger and Nimbus Sans L.
As an Ubuntu user, I see Arial, which is perfectly pleasant. On my Android devices I see the default
sans-serif font (Droid Sans I believe), which actually works rather well on mobile — you’d almost think that’s what it was designed for!
What else? Standard stuff. Few/no images, SVGs if anything
Beyond this, it’s really just the standard. The homepage of sustywp.com has no images and just one SVG which is loaded inline rather than by an http request. The CSS is minified. Everything gets Gzipped. The server is tuned with NGINX and Fast-CGI cache to serve content from memory.
Bonus SPA-like features without the work or code
When I was boring my girlfriend Daisy with my plans, I asked her how she felt conceptually about a website not having a navigation, and it instead being on its own page, found via a “menu” button. She thought it sounded ok. So when I came to show it to her, I watched eagerly as she clicked “menu”. Her response was that she didn’t really think about clicking to see the menu, and the menu appearing, as changing pages. This confirmed one of my fears that my previous obsession with eliminating page loads when building Single Page Apps (SPAs) is something that only really bothers web developery types. Most people don’t really notice it or think about it. So if you make your website lightning fast, the page loads themselves are almost imperceptible anyway.
$_SERVER superglobal and
HTTP_REFERER, but this breaks when using something like FastCGI cache to serve pages. I.e. for those pages there is no
- Finish reading Jeremy Keith’s book Going Offline so I can implement a Service Worker and make Susty even more performant.
- Look to see how I can implement Gutenberg. It’s going to add a bunch of kilobytes and that makes me sad! 😉
- Currently, sustywp.com is hosted in one data centre in London, and served globally from that location. This means that someone in Wellington, New Zealand for example is not going to get the full experience! I have a longer term plan of establishing my own little CDN of edge servers (each one hosted by a 100% renewable energy powered host in each location that I can find one) just running NGINX and serving cached versions of the site. This is a simplified way of how we do things on WordPress.com VIP.
The best thing about all this is that efficient websites means faster websites, which means:
- happier users
- better search engine placement
- happier servers
Originally posted on my own site.