How can we, as web professionals, help to make the web more energy efficient?

Domestic computer use simply isn't a big fraction of a person's total energy consumption:

e.g. this study[1] in the UK puts "IT" as <6% of household electricity use, which is itself a fraction of a person's total energy use.

edit: and this[2] indicates that datacenter usage is also not very significant.

Therefore, no amount of optimising web pages will make a meaningful difference to carbon output.

As web professionals, it's better if we direct our focus towards more productive areas around this goal -- by e.g. donating to relevant campaign groups, or using our tech skills to produce media on the topic.

[1]: https://assets.publishing.service.gov.uk/government/uploads/...

[2]: https://www.iea.org/reports/data-centres-and-data-transmissi...

Stop programming like a bunch of clowns!!!

Don't build websites on top of a million libraries which you don't need and put it in some container and host it in the cloud while using as much of the cloud service providers tools.

Build as much as possible from scratch and host it close to metal as possible.

Energy efficiency is a bad substitute for clean energy. We desperately need vast amounts of clean, emission free energy, to power electric vehicles, trains and tractors, the infrastructure used in their manufacture, the economy as a whole and the quality of life of the other 5 billion who lack internet.

The energy that we stand to save on the web, in the best case, is no more that the equivalent of a few points of GDP growth for some impoverished nation. It's less than negligible, it's net negative, because you are wasting the political and human energy optimizing irrelevant things and thinking you've made a difference.

Stop including megabytes of javascript in every page, and composing pages from 100s of requests to microservices. In short, keep things simple.

I don't believe asset and component delivery are the energy hogs this article implies. Actual computation uses more energy. Youtube transcoding the 500 hours of video it gets every 60 seconds uses much more power than too many unoptimized PNGs do. We live in a time where people will run their car to charge their phone. It's not js packages. The inefficiencies are in the chair, the users chair.

> “But Carl, some of us don’t have the luxury of building super high-performance, lightweight, and optimised sites due to client budgets and deadlines.” Well, I think you need to work on your craft, change your attitude and your priorities, or find another profession.

Well, I think my employer doesn't care much about this topic, so I feel like you're talking very condescending to me, while I have little to no control over issues like this.

One thing that I struggle with, as someone who is not a policy maker, is understanding the proportion of carbon emissions associated with different activities, for example, what would be the carbon emissions savings of these different options:

- The yearly energy savings of optimizing millions of web pages to reduce server side and local energy consumption?

- Banning personal vehicle diesel engines for 12 Months?

- Not shipping tonnes of tropical food across the Oceans for 12 months?

- Everybody not buying new clothes for 12 Months?

- Everybody not buying a new electronic device for 12 months?

I am not claiming that we should all go amish and bankrupt entire sections of the economy, my point is, these are all direct ways to curb carbon emissions but I have no intuition of how big of a dent in the overall emissions each option would make.

What are the carbon emissions that, if curbed, would provide the most bang for buck if you will?

Lot of developers don't care about performance at all. Knuth must be regretting his life choices when he knows webshits write O(n²) code when O(n) code would be equally straightforward, and allocate memory gratiously, misquoting "premature optimization is root of all evil". Most of them also have latest hardware and don't know the user experience / business consequences of this.

Lack of knowledge of proper computer science fundamentals among blue collar developers is also a reason for this.

I think there's so much that can be done with web design to make browsing the web more energy efficient, but in many cases users don't want or need a website – they just want some key data.

> "People just want to access content quickly, without distraction, without friction, and without it using a tonne of data."

Absolutely, most new websites for small businesses are 90% identical bloated single page scrolling Wordpress sites. When we visit those sites we're often looking for contact info, opening hours, menus, or maybe links to social media so we can interact with the company. So really we want ~100 bytes of data (e.g. address / socials / telephone / opening hours) but we have to download 5mb+

A small team and I have been working on an alternative to the web for structured data. It's a DNS-based protocol that domain / email owners can use to provide data direct to users:

https://www.num.uk https://news.ycombinator.com/item?id=24354559

Architect/programmer here:

Here is a list of how to be more resource efficient / cost effective:

1. Render dynamic assets to static html and cache them via a Content delivery network CDN. This will take far less cpu resources than rendering dynamic content and it will be faster to serve to the users.

2. Set reasonably long cache expire headers for content so that content are cached locally in the browser.

3. Use fast data structures such as hash-tables, tree structures that provides O(1), O(log n) lookup of your data whenever possible.

4. Use fast programming languages and frameworks such as Go-lang, C++, Rust, Scala and Java instead of slower languages. Fast programming languages uses less resources than slow programming languages.

5. This is one controversial since its not the current trend, but consider when to use Mini services / Monoliths instead of Micro services. A Monolith is a single process on one or more host it has access to local CPU cache and memory which is very fast. Mini services/Monolith will be more compute resource efficient than a Micro service where the service call has to be JSON serialized and travel over the network and then deserialized.

List of efficient web frameworks:

https://www.techempower.com/benchmarks/#section=data-r19&hw=...

List of search efficient data structures. Big Tech companies ask job interview questions on these data structures for reason of speed.

https://en.wikipedia.org/wiki/Search_data_structure

Not a word about the elephant in a room - difference made by underline server technology. Here is the latest example from yours truly: was running a test for a week on my custom http multithreaded stateful server written in C++ that calculates some complex programmable proprietary metrics and serves results as JSON. Beats the system it replaces more than 150 times performance wise sustainable. So that is 150 times less energy per transaction. Not shabby.

As to horrors of manual memory management - there are none as there is not a single place where my code explicitly allocates/deallocates memory. Modern C++ is pretty good in this department.

I'm trying to find a good source, but on phones, data size isn't as much of an issue as how long you have to keep the LTE radio powered for a full data connection. The worst thing you can do is progressively load content every 60s as someone scrolls or ping back to a tracking server every 60s.

Here are some Latency numbers every programmer should know (https://gist.github.com/hellerbarde/2843375):

  L1 cache reference ......................... 0.5 ns
  Branch mispredict ............................ 5 ns
  L2 cache reference ........................... 7 ns
  Mutex lock/unlock ........................... 25 ns
  Main memory reference ...................... 100 ns             
  Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
  Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
  SSD random read ........................ 150,000 ns  = 150 µs
  Read 1 MB sequentially from memory ..... 250,000 ns  = 250 µs
  Round trip within same datacenter ...... 500,000 ns  = 0.5 ms
  Read 1 MB sequentially from SSD* ..... 1,000,000 ns  =   1 ms
  Disk seek ........................... 10,000,000 ns  =  10 ms
  Read 1 MB sequentially from disk .... 20,000,000 ns  =  20 ms
  Send packet CA->Netherlands->CA .... 150,000,000 ns  = 150 ms

Most of your code optimizations will pale in comparison to a single disk operation.

So, maybe, you should buy more RAM? :)

On top of what the article recommends her is my personal pet peeve.

STOP using gazillions of nested DIVs only to achieve a single button. I know this is the result of frameworks but maybe, just maybe, somebody someday will start making a clean layout framework that uses TABLE instead of DIV. It's sooooo f*ing much faster.

Working from home would likely have a greater impact than anything else listed here.

If I'm not mistaken, the internet uses as much power as all of Germany, or less than 100 million people. This makes our choices as individuals more important than our choices as developers.

Drive less, fly less, consume less.

My first step is https://concise-encoding.org

All of this constant stringification/destringification just for another machine to read some transmitted data is massively wasteful, but we all do it because we want our data to be human readable, so we use JSON. But what if you could send as binary, with the ability to convert 1:1 to/from text only when you needed a human to inspect or input the data?

What if you didn't need to encode all of your non-numeric data into strings?

I've got many other steps in the pipeline to reduce our energy wastage, but this first one has taken awhile (3 years), and I still need more eyes on it to make sure nothing gets missed before I release in a few months.

I know this is a difficult thing to raise, but I question the assumption that the technologies underlying web frontends themselves are optimal for energy efficiency. Mobile devices are where power management matters the most, and this is where you find web tech used the least.

At the dawn of the present mobile era, there was WebOS, which was built with web tech. The original iPhone unveil showed a phone that only supported web apps, and there was no App Store at all. Android came out of Google, a company that at that point depended completely on web APIs for rendering. Something clearly changed soon after that point, as web technologies were cast aside as the major mobile platforms evolved post-iPhone.

Many people ascribe this situation to nefarious motives on Apple's part, and I am aware of their artificial restrictions, including the requirement that other browsers use webkit, the click delay, limited hardware API/camera access, etc. Still, this alone doesn't explain why the other players (especially Google) ended up prioritizing non-web apps.

I hasten to add that something is definitely lost in the mobile app store model, namely the freedom of the user and of the content creator to put things on phones without filtering by reviewers. However, I think that issue is orthogonal to the energy efficiency discussion above. And I would be overjoyed to see this resolved in a way that enhances user and creator freedom, without any energy efficiency loss.

I have worked with web tech for years, before I quit writing web apps about a year ago. I have spent the last few months learning Swift and Metal, and I can see the relative strengths and weaknesses in both web and native app paradigms.

Given the above, I'd like to hear what you have to say:

- Did Apple deprecate web apps simply because they couldn't control them, or is there more to it than that, as the above suggests?

- Do web technologies have a bright future as a frontend application platform, or will they continue to be eclipsed on mobile devices by Swift and Kotlin, SwiftUI and Flutter? Will this trend continue as VR and AR adoption grows? Why or why not?

Quite simply by becoming web professionals in the first place.

All of the inefficiency examples create unnecessary cost or worsen the user experience. It's well documented that most people work better and more often with fast tools. And there's lots of regular folks complaining that fashionable hipster websites are horrible to use. And lastly, lots of Javascript also increases maintenance costs.

So all of the points could be summarized as "don't make user hostile beginners' mistakes"

Now the more important question is: which company actually values its users / customers enough so that they won't outsource to the lowest bidder?

Stop cramming everything with fucking JavaScript for starters.

If you're running, say, a programming blog, stop sticking Google Analytics, "Like Me On Facebook", and any and all ads. If you've got a hankering to put the information out there, do that, and pretend it's like your old http://your.isp.com/~username web page. You don't need to fucking monetize it, it's a blog with your opinion which, like your asshole, is something everybody has one of.

I cofounded the Hackerfleet[1] Community, a (rather too small, join! :) group of sailing hackers and nerds.

Since we operate our tech stacks with batteries and often only solar/wind power, we try to come up with very energy conservative solutions.

One thing we couldn't do without: ARM CPUs even for servers, because they're quite energy efficient.

If you have any questions, i'll be checking this comment thread for a few days.

[1]: https://hackerfleet.eu

"Web professionals" - therein lies part of the problem: to turn a simple mechanism for self-publishing into an idiosyncratic ever-changing self-serving cottage industry.

You can always reduce consumption. The plastic problem would not exist if we stopped using plastic. That doesn't seem tractable though so we'll probably find ways to enable us to continue consuming more plastic... but we can still try to consume less of the stuff.

Same with energy. You don't _need_ your house to be "always on," etc. Turn out the light when you leave the room. Etc.

We could similarly not expect the sites to be "always on," and "instantly available," ready to deliver the highest-fidelity content as quickly as possible.

Yes, that keeps people engaged. But maybe we don't need more engagement. Maybe we have enough engagement going around.

https://hackaday.com/2018/10/08/perfecting-the-solar-powered...

Low-powered, on-demand, peer-to-peer, edge computing seems like a neat idea.

I'm not an economist though... I'm not really sure that websites contribute significantly to energy consumption.

Not the web, but abandon Bitcoin.

It feels like the major environmental cost is in the manufacture of new devices.

If software were properly optimized, I wouldn’t need to upgrade my machinery. We’d need one fewer open cast mines to dig out rare earth metals. Less shipping. More recycling.

(Related, but tangential to web dev: device repair.)

I have no idea what I’m talking about though. I come to this site to find people who do.

It's less about the web and more about the computations we're running. The stack end-to-end is inefficient because software quality is lackluster and deficient of craftsmanship. This is mostly because the hardware enabled this type of behavior.

The only way this is going to change is to change the hardware. I see this becoming possible as we transition to localized manufacturing where the individual only depends on themselves.

So as we get closer to chip fab happening via a 3d printer, and all hardware and software being local, we'll be closer to the energy efficiency goal.

You can see the trajectory already happening and IoT/Microcontroller/Etc boom. Lots of cool new projects are coming out with the "hacker-like" culture of old on energy efficient chips that can run amazing software powered by just solar alone.

Super cool, I have faith we'll get there soon!

Retire javascript

The overwhelming majority of websites could be implemented with the exact same functionality with just html, and we are here because insane demand for websites created an insane wave of non knowledgable web "developers"

Think videos are the obvious elephant in the room, more so than JS bloat.

One suggestion, use 304 Not Modified when possible, this saves the client re-downloading a document as well as saving any more server side processing that might've been needed to create it.

Always wondered why 'popular' JS libraries simply aren't simply bundled in with browsers. Perhaps could be a problem of preferential treatment but I think if the top dozen or so libraries/versions were bundled in then that'd potentially save a lot of bandwidth, latency, CDN usage, etc...

I'm not a huge fan of putting client-side rendering on everything, but I still feel it's unfair and shallow to put so much blame on it.

For an app getting more than a couple page views in a session, a SPA solution may provide significant savings on rendering and db queries. Combine that with resource caching and these effects extend to following sessions.

That is, of course, if the app was built with some consideration regarding overall performance. Unfortunately, not too many web developers (both FE and BE) seem to be overly concerned with efficiency.

A static site generator like jekyll or Hugo might be a good option if "real-time" dynamic content is not really needed - e.g. most blogs and news/magazine sites don't need to generate the page everytime (or even every so often then cache it). Just generate it once and serve the HTML.

Nothing beats the feel of a static site loading in - so snappy and fast (especially if CSS has been adequately minified/bundled too).

Wait, design is the big energy hog? I find that... well, in need of some evidence and data.

I was expecting something like using serverless, or serving only static content or something.

There's just no way that "write less JavaScript" is the big needle mover compared to right sizing and scaling your fleet. Right?

Also, rather than spending two days optimizing all this, wouldn't you see much more carbon removed by spending two days planting trees?

I’ve now worked in multiple organizations where I had to fight for years to get staging environments, or to upgrade off long-deprecated software, or to fix vital security vulnerabilities. We bicker with non-designers for hours, days, weeks over whether we need a modal.

You think these people will agree to optimize for energy savings? Not a chance, unfortunately.

I'm surprised nobody mentioned http://idlewords.com/talks/website_obesity.htm nor https://solar.lowtechmagazine.com

> "From data centres to transmission networks to the devices that we hold in our hands, it is all consuming electricity, and in turn producing carbon emissions. According to recent estimates, the entire network already consumes 10% of global electricity production, with data traffic doubling roughly every two years."

That's interesting. It's more than I would have guessed. I assume that's dominated by the energy used by data centers and whatever devices the users are using, and that all the switches in between are relatively cheap to run relative to how much they're used?

Anyways, my suggestion is the obvious one: turn off all that ad and tracking nonsense. That's incompatible with the business model of a lot of popular sites, though. A good fallback may be to encourage everyone to use ad-blockers.

Cached server side rendering. I’ve been screaming for years, Why make a million computers do something (composite values into a template often with associated calculations) one computer could do ONCE and then share. Its fundamentally flawed design and it’s such a enormous waste of energy.

Sometimes I recycle tabs instead of opening a new one :)

Just an idea: if we want to have an impact we should know what are the actual numbers, what is actually consuming energy. That could maybe be crowd sourced. Let’s say someone create a browser extension that does some voluntary analytics, such as counting requests, images and their size, video, size of scripts and styles. All of this gathered somewhere anonymously.

If it’s done by a trustworthy group and people start using it, we could have good information that could be used to understand what are sources of energy consumption over time from the point of view of users.

Again, that’s just an idea I got reading the comments here. And I know people here will dismiss it because of privacy concerns (that I mostly share).

The biggest thing web developers can do to be more efficient is stop the warfare against their users:

* Block all third party script requests

* Never access the DOM via a selector (500x slower in Chrome and 20000x slower in Firefox)

* Stop relying on 1gb of code from NPM to do your job for you

Saving yourself time and money is often more energy efficient.

Here is a small example:

For my blog site, I use Netlify to host - which auto deploys on a git push. My builds running on Netlify were averaging around 3 mins (every time I pushed whether it updated content or not).

I noticed the problem when I almost ran out of build time. So I changed it to build locally and now commit the build output inside my git repo. Netlify deploys in around 5 secs now since it is all pre-built static files - I’ll never run out of build time now.

My machine already has all the dependencies and cached build output, so it can build in about 20 secs.

In addition, I can handle build errors immediately rather than finding a failed deployment.