A Greener Website & Ruminations on Energy Consumption
Our website's a little different than it used to be. We're using less energy than before to deliver updates about our research, using less of your device's processing power to render content, and have some recommendations for how you interact with tech to reduce your energy consumption.
I've made some bold claims in the excerpt, so I'll start by introducing myself. I'm Jesse Benjamin, and I built the website that you're looking at right now. I'd like to preface this article by saying that I'm far from an expert developer, and I do not have perfect knowledge of all of the software and hardware I'll be talking about.
My goal with this article is to discuss what I've learned during the process of this site rebuild, how it's challenged me to be more critical of the way I interact with technology, and to make some simple recommendations to help people reduce their energy consumption.
Why rebuild a site that was serving its purpose well?
This whole story started when I caught wind of the growing discourse around the carbon footprint of certain web technologies. Email was the target of the zeitgest at the time, and when I thought about it, it made a lot of sense; data transfer has an energy cost - transferring more data requires more energy.
It sparked a lot of subsequent thoughts about how much data was being transferred as a result of my online behaviours - website visits, video streaming, software downloads, websites I build & manage, and the list goes on.
After a few discussions with Jenn, we decided it was important to reduce the carbon footprint of Adrift Lab's website. In the grand scheme of things this site's traffic is tiny, but as an environmentally-minded organisation, it's important to us to reduce our carbon footprint and to open dialogues about how common human choices and behaviours impact the world we live in.
The Shiny New Site
This is a Jamstack site built using GatsbyJS, delivered via Netlify's CDN, with an implementation of NetlifyCMS to allow editing by non-technical users. I'll spare any more technical details here, but I'll definitely be writing about them more in the future. The important result of this new approach is our reduction of energy usage in three main ways:
- Removal of dedicated server technology. Cloudflare has a blog post about how "serverless" systems and modern practices can drastically reduce energy usage
- A huge reduction in the amount of data transferred to view the site and its content
- A reduction in the processing power demands on devices viewing the site
The new architecture comes with a collection of other benefits and drawbacks too. For the use-case of a small, environmentally-minded organisation like ours, it's a huge net-positive, but I think it's important to cover the drawbacks, and consider how they might prevent larger businesses and organisations from adopting a more environmentally-friendly stack.
This site is a lot faster than before, and the performance improvements aren't just good for our carbon footprint. They also help improve our chances to be ranked highly in search engine results, and there's a wealth of well-documented research about improved site performance leading to more traffic, more conversions, and measurably better user experiences. As it turns out, improving site performance can be incredibly beneficial for business goals while simultaneously reducing energy consumption. It's rare that business & environmental interests have such a complete overlap, and it gives me hope for a more efficient web in years to come.
The new architecture of the site also enables us to work much closer to accessibility guidelines, and this iteration of the site has much better support for users who make use of assistive technologies like screen readers and keyboard controls to navigate content. It is not perfect, but it's leaps and bounds ahead of the previous iteration, and I'll keep improving things as I continue learning and honing my skills as a developer.
Another benefit of our new setup is a reduction in our annual costs. Our use-case is easily covered by Netlify's free offerings, so we've cut out the cost of a Squarespace subscription every year.
The clearest loss in this update is the content management capabilities for non-technical users. For me, it's faster than ever to implement changes on the site, but frankly, the content editing experience is worse for everyone else. I'm certain that choosing a cloud-based CMS like Contentful would have provided Jenn and the team with a better content management experience, but I chose NetlifyCMS based largely on a hunch that it wouldn't use as much energy.
In truth, I still don't know if this is correct, and that's due to a lack of technical understanding on my part. My general thought process was to reduce the energy cost of upkeep for dedicated services, and my current understanding of headless CMSs tells me that NetlifyCMS is only going to have an associated energy cost when it's put to use, as opposed to an always-available cloud solution like Contentful.
The other main downside to the architecture change is the time it takes to have changes deployed to the live site. An average update for us takes around 2 minutes to build and deploy. For Adrift Lab, that's not a huge issue - we don't really deal in hyper-time-sensitive content, but it's easy to see how this could be a major roadblock for larger businesses or organisations.
The unfortunate reality of the situation is this project took a lot of my volunteered time to complete. Small non-profit organisations like ours usually don't have dedicated volunteers with the technical knowledge required to build a site like this, and I don't want to discount the value of easier-to-implement solutions like Squarespace for small businesses and organisations to communicate in the online space.
If you zoom out and consider this project on a global scale, the difference in energy usage we're making is miniscule, and we could have achieved a relatively significant improvement by simply removing the banner video on our old Squarespace site.
What can we do?
If you're a web developer, it's worth considering how your development practices impact energy usage, and you may want to check out the Website Carbon Calculator for a rough estimate of the impact of sites you build.
If you're a human who owns a phone, tablet, or computer and accesses the internet, here's some recommendations which are heavily inspired by the American Council for an Energy-Efficient Economy's article on data center & internet energy consumption:
1. Consider your usage of streaming services
As I noted above, removing video content was a quick and easy way to make a significant difference on a website, and the same applies to user choices. Video content is very data intensive compared to other online activities, and reducing the amount of streamed video content you watch can help to reduce your carbon footprint.
By the same token, consuming visual content in lower quality is an easy way to reduce transfer size. You can select lower quality options in the Youtube player, reduce the quality settings in your Netflix account, and apps like Facebook & Instagram have options to prevent video auto-play and reduce transfer size by delivering lower resolution media.
2. Be mindful of data you transfer
Do you really need to send that email attachment in the highest resolution available? Do you really need to use video on that Zoom call? Are you really going to use that piece of software you're downloading? Sometimes the answer is yes, but sometimes it's no. You can reduce energy consumption of your online activity by only requesting or sending files or data if they really need to be transferred.
3. Close those tabs!
Keeping tabs open requires processing power, and most sites will continually transfer small amounts of data in the background. If you're not actively using a tab and not planning to come back to it any time soon, consider closing it.
4. Cancel unnecessary email subcriptions
This one's nice and simple - hit unsubscribe on all those marketing emails you never read! Sending and receiving these emails uses energy - it's wasteful the same way the printing, delivering, and throwing out junk mail is. You don't need to unsubscribe from everything, but if you've never actually read any of the emails from a mailing list, it's probably time to hit unsubscribe.
5. Don't stress too much
Once I started working on this project and researching energy consumption, I cut back all of my internet usage to the bare minimum, and it drove me a little mad. I think it's important to consider that while online services and functions do consume energy, they also provide a lot of value to people's lives, and digital solutions are often more efficient than their historical counterparts.
Streaming high quality video does consume energy, but it's worth considering the relative impact compared to physical mediums like DVDs which require large scale production and physical delivery. I don't know what those numbers are and what those comparisons look like, but I do believe in the intrinsic value of film, tv, photography, websites, and so much else that we consume online, and in a world still feeling the effects of a global pandemic, connection via the internet is as important as ever.
I think the answer to the nebulous question of "what do we do?" is to be mindful of the impacts of our actions and behaviours, to seek ways to reduce our environmental impacts, and to be open to dialogue around how we can make choices with compassion for our planet and each other.
Also, stressing out about things uses a lot of energy 😜
I've been volunteering my time to help with Adrift Lab's online presence for close to 3 years now, and Jenn laughs because I always say "it's better, but still far from perfect" every time I make an update to the site. I'm going to make her laugh again, because this is the biggest update I've made to date, and now I have more ideas for improvement than ever 🤣. I won't be making any big changes to this site any time soon, but I want to look into a few things in the future:
A different framework
I've been playing around wtih SvelteKit recently, and I absolutely love it. I love that the syntax is closer to plain html & css, and the bundle size is generally smaller than React. I do miss some of the conveniences afforded by the more mature React ecosystem, and would still have to favour React for any project that involves anyone other than just myself in any way.
Update: if you're a developer and interested in SvelteKit, I've made a starter blog project which you may find interesting.
Environmentally friendly design
I'm a big fan of logos with versatile applicability, and want to dive deeper into how designers & developers can work together to create designs and design systems for brands from the ground up that are versatile, visually appealing, and conducive to environmentally friendly web development practices. For example, if I update the logos on this site so only the icon is rendered by
svg, and the accompanying text is rendered using the already-loaded font files, we'll be saving a few extra kilobytes for each session.
Better content management
Like I mentioned above, the content management system could use some work. I need to spend more time digging through the NetlifyCMS docs and writing a more advanced config so I can provide a better editing experience for non-technical users.
Thanks for reading
If you've stuck it out to the end, I appreciate you reading. If you have any thoughts about what I've written, or any suggestions for ways we can further reduce the carbon footprint of our site, please send me an email, or get in touch via our contact form.