Home > Designing, Others > Thinking About Power Usage and Websites

Thinking About Power Usage and Websites

September 21st, 2020 Leave a comment Go to comments

Gerry McGovern asked if I had any insight into energy consumption and websites. He has a book, after all, about the digital costs on the planet. He was wondering about the specifics of web tech, like…

If you do this in HTML it will consume 3× energy but if you do it in JavaScript it will consume 10×.

I would think if you really looked, and knew exactly how to measure it, you could find examples like that. Say I wanted to move an element across the screen. If I wrote a setInterval loop in JavaScript that incremented the left position on the relative-positioned element by one millisecond, I’m 99% sure that takes more literal electricity to do than if you were to do a CSS @keyframes animation over the same time where you changed the transform: translateX() value. In that example, usually, we’re thinking about performance moreso than energy consumption, but that’s interesting right away: does good performance map to lower energy usage? Probably.

Researches have looked into this.

We discover a statistically significant negative correlation between performance scores and the energy consumption of mobile web apps (with medium to large effect sizes), implying that an increase of the performance score tend to lead to a decrease of energy consumption.

They were testing mobile web apps on Android using Lighthouse scores. I can guess that maps pretty well to other platforms and other performance metrics.

I’m glad the research so far maps to what I would logically expect to be true. Things that lead to poor performance are things that take energy. Imagine images. You’ll be dinged on performance scores for serving too large or unoptimized images. Imagine the performance implications of that. There are two images sitting on a server, a large one and a small one. Which one takes more electricity to travel to some user’s computer? The large one. Which one takes more processing power to parse and display? The large one. Which one occupies more memory (which uses electricity) for the duration of it’s life on screen? The large one.

The less across the network, the less electricity.

The less your browser has to do, the less electricity.

Some ad that auto-refreshes itself every few seconds? Not only is it annoying, but it’s bandwidth-wasteful and thus wasteful with electricity. Whenever you have to resort to polling (i.e. making a network request over and over) rather than something event-based like web sockets? That’s using electricity that you may not have needed to use.

We know that CDNs are good for performance too. Rather than a file (like an image) needing to travel across the world, it comes from a server much geographically closer on a server designed for that job. This is where things get a little more murky to me.

With performance as our goal: objective achieved. With low-energy consumption as our goal, are we there?

It has been studied, but unfortunately, I can’t tell what the conclusion is from the abstract alone. In my mind, things are complicated by the fact that servers around the world are storing copies of these assets, and when the assets change, it’s not just one server where they update, but again, servers around the world. There has got to be a balance between the propagation and duplicative storage as far as the savings that would be realized by the efficiency of saving requests.

Speaking of storage efficiency, I’m certain that storage just sitting on disk takes a lot less electricity than files being sent over networks — but it still has a cost. Say you saved a copy of every file every time you changed it. Say you saved a complete copy of your website every time you deployed it. Useful? Sure. Does that cost electricity? It must. There must be some balance to strike there.

Gerry was asking me about particular technologies though. I can think of another big deal thing in CSS land: dark mode! Yet again, it’s been studied. Dark mode saves power.

Dark Mode can indeed reduce the display power draw by up to 58.5% at full brightness for the set of popular Android apps that we tested! In terms of whole phone battery drain reduction, that translates into 5.6% to 44.7% savings at full brightness and 1.8% to 23.5% savings at 38% brightness.

And what about comparing technologies? I suspect it’s far more about what that technology (or language) is doing than the language itself. For example, I can build a little area that opens and closes in HTML with a

element. Is that more energy-efficient than creating that area by attaching a click handler on a button that toggles the class of an element that visually opens and closes it? I kinda doubt it. I’d bet the electricity being used in the re-paint/re-render steps that the browser is doing and the languages behind it are less relevant. And yet! If I made the browser download a 50 KB JavaScript library just to implement my little open/close element, then yes, it does matter, and the JavaScript version is less efficient.

In that way, just as good performance generally maps to less energy consumption, I’d bet that adhering to the rule of least power generally maps to less energy consumption as well.

Sick of me guessing at stuff? Fair enough.

Jack Lenox’s article “How Improving Website Performance Can Help Save The Planet” on Smashing is a better deep dive. He points to websites that will test your site. Website Carbon Calculator is one example and it states:

Calculating the carbon emissions of website is somewhat of a challenge, but using five key pieces of data we can make a pretty good estimate:

1. Data transfer over the wire
2. Energy intensity of web data
3. Energy source used by the data centre
4. Carbon intensity of electricity
5. Website traffic

The testing code is open source.


The post Thinking About Power Usage and Websites appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.