The following is what I wrote for this year’s DLINQ Digital Detox. It was strange writing without footnotes. It’s also a lot less of my normal writing voice. I was writing for a bunch of strangers rather than you, my dear readers.1
It’s easy to use the web without thinking about it much. Modern processors, increasingly accessible broadband, faster cellular options, and better batteries all work together to make consuming vast amounts of data as seamless as possible. That data consumption is directly tied to energy consumption in ways that aren’t obvious. Seeing Rabih Bashroush’s research on the energy consumed by streaming Despacito seven billion times on YouTube (now at 7.7 billion views) opened my mind to the complexity involved in calculating energy usage across our distributed systems.
The challenge of this post is to talk about energy consumption on the web in a way that makes sense to people (most of whom don’t build websites) through the lens of rebuilding a website in a more energy efficient way. I’m going to limit technical explanations and fight my desire to wander into the energy consumption of data centers, crypto-trends, wifi vs cellular data, etc. I will link out to lots of different pages where you might pursue some of these asides if it interests you.
Walking the Talk
Since the topic of this year’s Digital Detox is the impact of technology on the environment, I decided to re-create our Digital Detox page putting energy-efficient design principles into practice. I wanted to better understand the concepts and the kind of work involved in making a website more energy-efficient. Could I make an attractive and useful page that was also very efficient?
The new site needed to acknowledge DLINQ’s existing expectations for writing on the web. It was not reasonable to expect the team to start writing HTML and uploading it to a server via FTP. I also needed to keep my own work within reasonable bounds. I wasn’t in a position to commit massive amounts of time to this project. I needed to keep it reasonable. I set a rough limit of 10 hours for doing the research and building the site.
In the Beginning
Since I was going to try to replace our current Digital Detox page with a more energy-efficient model, I started by analyzing our existing page. This would provide concrete data to evaluate progress against. I looked for tools that would let me analyze webpage energy usage. One of the tools that I found particularly useful was websitecarbon.com. I liked that the methodology was explained and that the code was open source.
The first warning sign I had was that the evaluation was taking a long time. The analysis site warned me repeatedly: “We’re sorry, this seems to be taking longer than usual. The test requires a full load of the page, so the bigger the website, the longer it takes.” Time, as it does, continued to pass. The report finally loaded and it was not good news.
The Detox page review indicates our page was “dirtier” than 99% of web pages tested generating roughly 35 grams of CO2 with each visit. Ouch. It certainly sounded terrible but I wanted a better frame of reference for grams of CO2. I felt that gasoline was something I understood a bit better than the numbers of trees, bubbles, and sumo wrestlers the site used as metrics. Turns out, burning a gallon of gasoline creates about 8,887 grams of CO2. So it would take about 254 visits to our Detox page to equal the CO2 produced by burning a gallon of gasoline. I found that fairly shocking.
To help balance out this relatively bad news, I wanted to look at something on the opposite end of the spectrum. What does an amazingly energy-efficient website look like?
In September of 2019, I wandered across an article on We Make Money Not Art posing the question “Can you design a website on a (very) limited energy budget?” That article led me to an amazing breakdown describing how Low Tech Magazine rebuilt their website. It’s an impressive explanation of how they radically reduced their website’s energy usage and fully integrated the practices they espouse.
“. . . this website runs on an off-the-grid solar power system with its own energy storage, and will go off-line during longer periods of cloudy weather. Less than 100% reliability is essential for the sustainability of an off-the-grid solar system, because above a certain threshold the fossil fuel energy used for producing and replacing the batteries is higher than the fossil fuel energy saved by the solar panels.”
I was inspired by their commitment and also appreciated that they documented technical aspects of their process so that others might benefit. I’ve found that seeing something that stretched my mind like this impacts my day-to-day understanding and how I build websites in general. Since then I’ve kept an eye out for opportunities to apply some of the more aggressive techniques that Low Tech Magazine used. I may not be running sites on solar power but I do think about websites very differently thanks to Low Tech’s efforts.
Going into this project, I had some beliefs about web page energy efficiency that I developed over the years. This wasn’t knowledge I pursued specifically but bits and pieces of things I picked up over time. As I started to think about building this site, I realized that I wasn’t entirely sure which of these ideas, if any, were true. Prior to doing any new learning, I thought I’d better evaluate my preconceived notions.
Are dark colors more energy efficient?
I remember seeing information floating around the Internet about how much energy Google would save if they would turn their search page black instead of white. I think the original article behind this idea was this Blogspot post that made it to the front page of Digg . . . in 2007 (which explains both Blogspot and Digg–two defunct platforms–being in that sentence).
While it may seem like there’s a straightforward answer to this question, there are a number of complications. In the old days (2007), dark colors gave you a clear energy advantage when the site was on a CRT monitor (the big old clunky monitors of yore) but dark colors didn’t matter much for LCD displays. CRTs, regardless of website colors, were much less energy efficient than LCD displays. In more recent times, you see darker colors giving energy benefits in OLED displays but OLED displays are still a fairly small share of the market.
In the end, I didn’t see significant enough differences for going with darker colors. There were too many variables involved and too little overall energy savings for me to feel it made sense to entirely restrict the color palette. Given more time, I’d probably make a dark color scheme that would be applied if I could detect whether the display was OLED. In the long term, I need to look harder at palettes that take advantage of dark colors.
Do flat files beat database queries?
Another idea around energy efficiency that I picked up somewhere along the way is that any time the site has to query a database more energy is used. In the early days of the web, you were mainly dealing with simple HTML pages. As more complex ways to write on the Internet developed, sites and site authoring software became more complex. Content management systems (CMS) that rely on databases to hold the content, were developed. This includes software like WordPress, Drupal, Omeka, etc. There are many advantages to a CMS but what does it cost in terms of energy usage?
In the end, I couldn’t find anything specific about energy usage and the kind of small site-level database queries we’d be dealing with. I did find quite a bit about database queries impacting page load speeds. There are innumerable articles on how to optimize WordPress database queries. Even without specific CO2-related data, I feel confident that flat files are faster than database queries and, as a result, are more energy efficient.
The need for speed
It seemed to come down to this: fast websites are efficient websites and small websites are fast. There is a huge amount of information on making websites faster because it impacts how Google indexes your site. Using speed as a proxy for energy efficiency, I began looking at the elements that were slowing down our existing Detox page.
The major element impacting speed was having over 40 images on the page. The number of images is exacerbated by their large size. The WordPress theme we’re using is embedding images at the largest possible size. The article images at the bottom of the page are as large as 5000 pixels but are being displayed in 300 pixel boxes. This is massively inefficient. Properly sizing these images could result in data saving as great as 15MB for a single image. While not every image would result in that amount of savings, there are significant opportunities for improvement.
Wow. All this points to a lot of work we might do when we rebuild this particular page (and the site in general) in the future . . . but I’ve got limited time and my goal here is to build a proof of concept page rather than fixing the existing site. So enough analysis, let’s start making something new!
As I approached the redesign, I set the following goals.
- Build a very fast/small website.
- Use content written in WordPress (because that’s what the team was already using).
- Avoid database queries to get that content.
- Explore what I can do visually with CSS in lieu of images.
- Limit the technology involved so it didn’t become too complicated to explain.
This kind of simple site is referred to as a “microsite.” It is focused on doing a specific set of objectives and often differs visually from the main site.
Writing and Getting the Content
WordPress remained our authoring tool and the process for writing articles on WordPress did not change. To get the content from WordPress into the microsite, I opted to use WordPress’s JSON API. JSON is a particular kind of structured data that I can use to populate a template. This data source is built into WordPress and you can see what WordPress JSON looks like here.
To make this happen even faster and more economically, I wrote a little bit of PHP so that every time someone wrote a WordPress post in the “Digital Detox 2022” category, the function would be called to copy the relevant data to a folder. That allowed me to access the most recent Detox data without generating any additional database queries.
I wanted the page to have interactive visual elements and to feel like more than plain text but without the overhead of lots of images or custom fonts. I decided to pursue that aesthetic in a few different ways.
There is a single image in the template. For the background, I used a topography SVG that I embed within the CSS of the site. SVGs compress well and have other advantages when scaled. They’re also easy to add as text within CSS. This avoids having an additional external download. The Detox background SVG weighs in at 93KB.
The rest of the visual design is done via CSS. The fonts are default sans-serif to prevent the extra data associated with custom fonts. I applied some hover effects for the buttons and did some minor animations for certain links. Blockquotes get a special visual treatment (which you can see towards the top of this post). The title is made to look 3D by layering the CSS text-shadow effect. You can see exactly how that works on this Code Pen example.
The total weight of the CSS is 102KB. Realizing that more than 90% of that file size is the SVG is causing me to rethink that choice. It’s amazing how little choices add up. I’ve also found that writing the actual size of the data resulting from these choices is a really powerful reflective pattern. Even when I felt I was being particularly attentive during the construction process, writing the exact number down changed my perception of size.
In this post, I opted to use an image but I didn’t want to take the time to integrate a server-based compression option so I looked for ways to do something similar in PhotoShop. I tried some bitmap dithering but ended up using some aggressive 4 color GIF compression to take a 247KB screenshot down to 6KB. That’s a lot of savings but it’s worth noting that this single, highly-compressed image is as big as both my HTML templates put together. These things add up! Is this image really conveying something important? Do I really need this image? Is it optimized for the way I’m using it?
Reducing HTTP Requests and Minifying
Minifying removes line breaks, spaces, etc. in an attempt to use as few characters as possible. You can see an example of what that looks like in the HTML view of this CodePen. Programmers do their editing in the “beautified” view with line breaks and then minify the code when moving to production.
35.34 g of CO2
0.14 g of CO2
I feel pretty good about those improvements. This is just a proof-of-concept site but I learned a good deal in the process and hopefully was able to explain some of it. This project has really shifted my ideas around size. When I started, 93KB for the topography image felt small, especially when I was comparing it to the multi-megabyte images we were using on the original page. Now 90KB feels like a real extravagance. Activities like this help reset the bar.
I know that most of you won’t be building websites from scratch, but hopefully this exploration gives you a bit of insight into how websites are built and how design choices impact energy usage.
1 All seven of you. Maybe less than seven, given this site has been solely weekly links posts for the last several months.