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 they interest 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 uses 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 toward 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 the 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.

Take Action

Many of you may not make or contribute to websites. You can still do things that impact your digital energy usage.

  • Avoid sites that make your computer’s fan run or that quickly drain your phone battery. These are signs that the websites are inefficient.
  • Consider using “dark mode” on your phone or computer. It takes some getting used to but this results in energy savings on OLED screens.
  • Download data over wifi when possible. Wifi downloads use roughly two times less energy than cellular downloads.
  • Turn off unnecessary cloud storage.
  • Avoid streaming video if you aren’t watching it.

If you make websites or contribute to them, there are a number of ways you can improve the energy efficiency of sites.

  • Evaluate your image use. Do you really need that picture? Is it optimized for your particular use?
  • Make reflections on data size part of your authoring process and review your site efficiency regularly.
  • Keep things as simple as possible. While new technologies are tempting, keeping things simple and streamlined has all kinds of benefits.

Keep Reading