Detox Site – Energy-conscious website breakdown

Screenshot of the carbon rating saying "Uh oh! This web page is dirtier than 99% of web pages tested."

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.

Screenshot of the carbon rating saying "Uh oh! This web page is dirtier than 99% of web pages tested."

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 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.

Additional research confirmed my expectations that better speed performance was correlated to better energy efficiency. That means I can use load speeds as a primary metric for evaluating the energy efficiency of our pages.  Modern browsers have tools built in to help with these evaluations. I looked at our existing Detox page through Chrome’s Lighthouse tool. The performance score was 66. That’s not as bad as it could be. It took 3.1 seconds for the page to become fully interactive. Lighthouse pointed out significant issues around image size optimization, unused javascript, and unused CSS.

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.

Preconceived Notions

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.

While large media files are one place where websites gain “weight,”  there are other places that are a little less obvious. Modern web development patterns often make use of javascript frameworks (like jQuery) and CSS frameworks (like Bootstrap). Often much of that framework goes unused but is loaded in its entirety. With WordPress themes, you can end up with javascript and CSS being loaded by the theme and by each active plugin. Our Detox page ends up loading roughly 65 separate javascript files and 7 separate CSS files. As a result, the page ends up being 74MB with 124 separate external requests.

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!

The Redesign

As I approached the redesign, I set the following goals.

  1. Build a very fast/small website.
  2. Use content written in WordPress (because that’s what the team was already using).
  3. Avoid database queries to get that content.
  4. Avoid any external libraries for CSS or javascript.
  5. Explore what I can do visually with CSS in lieu of images.
  6. 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 built two basic HTML templates. One template was the main homepage (6.5 KB) which had the introduction and an index to the posts. The other template was for each individual post (2.5 KB). Think of these pages like mail merge templates. The JSON is like an Excel sheet of data that slots into the merge fields so a single template can be used for all of our Detox posts. Javascript then uses the stored JSON data to populate the content of the pages and display them as HTML.

The Visual

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.

Image Compression

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

Each call from the web page to something outside the page slows things down. That includes requesting images, videos, javascript, css, etc. One way to reduce this is to build these elements into the page when possible. Generally, it’s not done during the construction process because it makes building and editing the page more difficult. Most programmers like to have their pieces cleanly delineated and organized.

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.

I could have minified the HTML, the javascript, and CSS and also included all those items within the page. I chose to do that only with the javascript. The overall savings weren’t massive. Minifying the main index template did cut the size in half . . . but half was only 3KB and that is not much in the scheme of things. I saw a similar 3KB in saving by minimizing the CSS. Given this was meant to be a learning example, I left most of it uncompressed so that it would be easier for people to read and learn from if they happened to look at the source code.

Final Statistics

Original Page

New Page


Page size

75000 KB

187 KB


Page speed

16.34 seconds

1.2 seconds


Carbon produced

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.

The same design choices that improved energy efficiency also lead to the site being more accessible and easier to maintain. Building with the basic technologies of the web (HTML, CSS, javascript) also leads to sites that will last longer. It’s always interesting how many additional advantages come from focusing on simplicity and functionality.

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.

3 thoughts on “Detox Site – Energy-conscious website breakdown

  1. Boy this takes me back to when I finally learned to write the basic HTML tags from scratch. People were never as impressed as I was that typing this out by hand, but it was a real live web page, just need to FTP it up to a web server. Boy did things change after that. PHP, MySQL, CSS, frameworks, Javascript, AWS, list goes on and on. But this challenge, to look at the impact of all that list of going on and on, and the size of web pages is fantastic. What was once a bunch of tags and markup are now apps, on smartphones, like TikTok and all delivered as web pages. Revisiting this scope creep, and minimizing the impact is a virtuous, but very beneficial thing. If still used analog/acoustic modems running at 56k/sec things would have creep-ed less, I dare say.

    1. Every so often, I’ll look at the stuff I’m writing and be fairly amazed that it works and that I understand any part of what’s happening.

      I always think of the scope creep when people tell me that 5G will change everything.

Comments are closed.