How can we, as web professionals, help to make the web more energy efficient?
cmhb.de
cmhb.de
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...
If I hypothetically ran an inefficient 500W dedicated server 24/7 for one 8760 hour year, and my electric utility produces 1 lbs of CO2 per kwh, that's about 2 tons of CO2 due to my programming habits per year.
Last year, I had a long commute and an inefficient vehicle. 1 gallon of gas produces 20 lbs of CO2, I got about 18 mpg, and drove 25,000 miles, mostly due to commuting, so my driving added 12.5 tons of CO2 to the atmosphere.
Instead of making my computing more efficient, I changed jobs and vehicles. Now I drive 2.5 miles to work, at 30 mpg, fill up maybe once a month instead of twice a week, and am much happier for it! If I spent extra time to do more efficient programming, I could have decimated my server's power bill, and could have saved almost 1.9 tons of CO2, but by spending that time looking for a better job and better commute, which were far more extreme, I saved about 10 tons of CO2 instead.
I mean, I'm certain I'm not hitting 500W just on my MBP, but with the TV, and Switch, and the rest.
2 tons? That's staggering. Would it really weight 4000 lbs??
That's absolutely a mind blowing moment for me and I'm probably going to spend some time in the near future figuring out how much carbon my relatively low footprint (no commute, bike lots, public transportation the rest, etc) lifestyle is producing.
I think I've got some old electricity bills, and of course it must depend on your power source.
Just wild to think about how many _tons_ of CO2 are now floating around because of just my lonesome if a computer can produce multiple tons a year.
All of us only have a finite amount of time/attention we can spend on things like the environment. It we truly care, then it's our obligation to spend that time on the changes that have the biggest impact.
Let's discuss energy usage of the web once it makes its way into the top 100 areas of potential impactful improvement. Until then, let's put our effort into pressuring our politicians into enacting meaningful change where it matters.
And it's similar with computers, as you've stated (especially with Laptops that are already pretty energy efficient).
I'm not sure what we can do as web professionals honestly, but as technologists in general, maybe more of us can apply our engineering mindsets to actual climate change problems instead of building a 50th ad analytics platform.
Any suggestions on how can you do that as an individual? You can easily create a generic software product alone, but to helping the climate change is really hard. OP asked exactly this, what can we do. So, what can we do instead of the 50th analytics platform?
I know it's a small percentage of overall use, but if enough people start using solar to charge their devices and maybe in the future laptop batteries, cars and houses it's a step in the right direction
The biggest offender is the AC in the summer in the US... office is so cold people have to bring sweaters and vests
If you truly want meaningful betterment you need metrics to focus your time and effort where it will have the most impact. If you spend all your time focusing on the most insignificant thing you can make massive progress in that thing and no progress toward meaningful betterment.
Focus is very important.
https://www.epa.gov/ghgemissions/sources-greenhouse-gas-emis....
Overall I'm not that concerned about our usage as it's not that bad and the industry is already rewarded for producing more efficient machines to compute.
That said, I've always thought it would be a cool project to use formal methods to prove efficiency properties or to quantify and prove the trade-offs between some more efficient algorithm and a greedier algorithm (especially in distributed systems.) But, most of that feels like developer mental masturbation in comparison to the much more egregious sorts of inefficiencies facing us (many of which require both social and technical solutions - the social one being the hardest.)
Sure your phone is using almost no power, but the network infrastructure and the servers you are using use a ridiculous amount of power.
Why does it matter? Isn't any improvement, by definition, a good thing?
If changing some of our programming methodologies saves 1% of the world's energy, that's massive.
1% of UK energy would be 22TWh — a massive amount of energy. Just because when it's expressed as a percentage it's only 1% doesn't mean it's not worthwhile.
Some things are a no-brainer, like allowing remote work when possible: that's an enormous energy savings.
It also means that development speed is much more important than execution speed in most cases. For example, yes, Python is a "slow" language. But in almost every case, it makes more sense for devs to deploy a website in Python than, say, hand-tuned assembler. The latter may require fewer clock cycles to run, but it's going to require 100x the resources to implement. That gets more difficult to quantify if you're trying to compare, say, Rust vs Go where both require similar amounts of development effort and the end performance is similar, but I think you can reasonably say that modern, high level languages are more carbon efficient than lower level ones that take longer to develop in most cases (like, that might not hold in cases of supercomputing where you're executing the code a gazillion times in parallel).
"How can we, as [profession], help to make [x] more energy efficient?"
It doesn't take long before that starts to add up.
I find these “as a profession” enactments more to be self-congratulory rituals than anything else. It is like trying to clear your disk storage space through deleting thousands of 1kb files while gigabytes of old movies are staying there hogging the most space.
Besides, I don’t understand why people has to be reduced to their professions. We are also citizens and voters, and the lion’s share of the change can only be done through policy.
The saying goes penny wise, pound foolish. Sometimes it is indeed foolish to focus on micro and miss the greater perspective.
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.
> Build as much as possible from scratch and host it close to metal as possible.
Citation needed. Running your site in a container on a shared host will be significantly more energy efficient then running hardware. It's silly to claim otherwise.
And the idea that the quantity of js libraries before compile affects energy consumption is a stretch as well.
The issue is how many computations you do at runtime. That is completely unrelated to third party libraries.
Edit: For an example, look at the app store for the oculus quest: https://www.oculus.com/experiences/quest/ - That site is ridiculously slow for what it actually does: Static text + images. And the current state already is way better than before! Almost all content is either static (the apps) or cachable (the ratings). There are barely 100 apps in the store, so this isn't exactly a case where there have to be hot updates every few seconds. This should be rendered server-side, cached, and then sent to the users as static html. The world could save literally tons of CO2 with proper design here.
Probably not. Running your own hardware implies more total hardware because you're not going to be able to saturate your hardware as efficiently as Amazon/Google/MS/etc. Moreover, you'll need to hire more people to work on that hardware (doing the work that Amazon/MS/Google do for you--and let's not pretend that cloud provider work is trivial).
That said, I don't exactly understand the calculus here because it's not like you're creating people who wouldn't otherwise exist for the sole purpose of operating your hardware.
> The issue is how many computations you do at runtime. That is completely unrelated to third party libraries.
Presumably the logic is that third-party libraries cause bloat, and bloat that needs to be sent to the client every time they reload your page (modulo cache hits). And it's certainly far more energy intensive to send a megabyte across a continent than to load it from memory into CPU cache or whatever.
Citation needed. Do you have some linkable metrics on how all those JS libs are reorganized and optimized (similar to how a compiler might do it on native code) such that the call to overlay or animate on a web page doesn't call through a sizable portion of those libs on every call?
If you write hello world in rust, you wouldn’t act as if the generated binary has all of the runtime dependencies of of the compiler, unit test framework, formatted, etc. So why does JavaScript get the same treatment?
It certainly depends on the scope of the site. My personal sites? If they run on their own bare metal, it's a waste because they're idle to nine nines. My previous work sites? www filled up four machines, so bare metal was more efficient.
What would be most efficient for my current sites is an old school shared host --- no containers, one httpd, etc. VPS is more fun, but you can't fit as many mostly idle customers into a single box with that.
Your site is only busy for 31 milliseconds per year?
For the "client side":
The web is responsive by default, making it not friendly to screen readers/phones takes extra work.
Semantic forms are great. You're writing a machine readable description of an API that auto generates a GUI. Theme it with some CSS and leave it alone.
No one likes downloading piles of javascript to load text documents.
Oh, the irony of the iPhone. When it was launched, its unique proposition was that it was the only phone which could render normal webpages, while previously specially tuned XHTML code and handheld stylesheets were required. And what did we do with this? We started the era of specially crafted mobile sites and mobile first.
Still, both then and now mobile requires reducing options to avoid lots of zooming and panning. And less JS is better.
Not discounting the necessity of mastering the language to be a strong engineer. However the framework being used is just as relevant, if not more so, than the underlying language
One of course wonders what else my computer is doing to render a piece of text/graphics I want to read/view and if all that is necessary and why I have 1Gbit Internet and still feel like I was on modem (sans blinking lights, linkup sounds and phone bills).
Unfortunately, the person or people that will try more energy efficient client side will loose to ones that will use the newly gained performance to waste it on another cool effect.
This would be great but it won't happen without monetary or regulatory intervention. The industry is hell bent on driving the cost of software to zero. Security, performance and accessibility are always the last to see any investment. The baseline seems to be as long as your website doesn't piss people off completely then it's enough.
Wouldn't it be less efficient to host something myself than to use some cloud provider?
The one major improvement over renting a VPS is that I've now got a large RAID array with many terrabytes of storage, where I previously only had a few hundred gig to play with.
While a server in a typical DC would use way more power than a home system, it's also theoretically possible that they are running at near 100% load, meaning all that energy is used doing SOMETHING, whereas your home PC is burning watts at idle.
I'm often interested in older/cheaper/less-popular articles/products/bits of information, but I'm often forced to scroll eternally or perform several clueless searches to find what I want to find. I can only imagine the extra, useless database queries infinite scrolling requires... not to mention how much and how thoroughly I hate it as a user.
More realistically, maybe don't cherrypick ideas to make up correlations that don't really make sense, and instead do actual environmentally net positive things like buying less stuff or donating
This was my first thought too. It's frustrating to see these questions when the answer is blindingly obvious to someone who takes even a small amount of time to do research. It makes them read as if they're all asked in bad faith, of which I am not convinced they are not.
come on guys this is obviously sarcasm
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.
We need both.
In a more distant future, we'll be able to use energy to clean up the damage from using a dirty energy source. When that's possible, when you'll be able to wrap full cleanup costs into EROI, then "clean energy" will only mean "more efficient energy source".
Efficiency gains affect only tiny slices that are outpaced just by growth. They serve to be nothing more than a distraction for intelligent people to sink their time on and feel helpful when they are not.
Clean energy works and the solutions are simple but difficult to implement because it has to be replicated all over in the face of politics and NIMBYs. Efficiency gains are a waste of time but they are attractive to engineers in various industries because they are intellectually challenging and narrow enough to be easily implemented.
> In its new report Making Mission Possible – Delivering a Net-Zero Economy, the Energy Transitions Commission (ETC) shows that clean electrification will be the primary route to decarbonisation, complemented by hydrogen, sustainable biomass and fossil fuels combined with carbon capture. It urges governments, investors, corporates and civil society to work together to accelerate the deployment of zero-carbon solutions before 2030 to put mid-century targets within reach.
The first step:
> Speed up the deployment of proven zero-carbon solutions – governments, investors and corporates need to work hand-in- hand to build up massive capacities of zero-carbon power generation to enable the clean electrification of the economy.
The focus is on generation, not reducing consumption.
Sure, it won't solve the bigger issue in one fell swoop. No single action will. Instead, the way to realistically make progress is via the accumulation of small improvements everywhere.
It could be 10% by 2030, based on projections made by experts in "sustainable ICT", which sounds self serving to me, and likely to ignore the massive energy demands of growing nations in other sectors.
Thats what the infrastructure does not what it is used for.
For example those bits are analytics and algorithms used by logistics companies so they can transport goods more energy efficiently saving a lot more energy than was spent on the computing.
Probably the most impactful thing you could do is to create web experiences that adequately substitute for carbon-intensive offline experiences. Teleworking, for example, is much cleaner than commuting long distances by car.
If you watch from around the 1h22m mark, you will see that he conceeds there is no such thing as "energy conservation", and that what he argues for actually is an increase of at least three times the in price of energy and food. Well, that's a non-starter even if you accept the philosophy, it will lead to revolutions and regime changes, it cannot possibly work.
So we absolutely need to maintain the relative standard of living, while significantly cleaning up energy. A 5x drop of our carbon intensity can lead to a more or less ecologically sustainable world economy where billions can enjoy the western standard of living without fucking up the planet in less the a century.
I do agree though that with unlimited energy many people will want multiple vacation mansions each somewhere in the wilderness. We need to handle that like we do with carbon emissions, limit it and tax it to high heavens.
Also software is really very inefficient and a lot of it runs on batteries.
There isn't much focus on the end to end energy usage (I've only seen a couple of papers over the last 10 years or so).
I have no idea how much energy it takes from the place this page is served to it being rendered in the browser, that information should be available so we can make things more efficient.
I think the biggest issue now is not ability to generate energy ( we have passive and active green energy sources ) but Storage.
And It would probably be for the best to find kinetic ways to store and release energy. Ofc I might be wrong and in the end batteries and solid state batteries solutions might be the winner. But I think kinetic storage is kinda low hanging fruit not many companies are looking into.
Also kinetic energy storage usually shouldn't degrade as fast as fluid based batteries.
for (let x=0; x < 10000; x++) {
if (x===0) console.log(x);
}
for (let x=0; x < 10000; x++) {
if (x===0) {
console.log(x);
break;
}
}
This is the basis of most optimization work - you're optimizing code to do the minimum amount of work, and very often that means writing more code. A moderately complex React/Vue/Svelte app will be much more energy efficient than a naive vanilla JS alternative because most frameworks to clever and hard things to reduce the amount of work that's done in order to increase performance, and a side effect of that is using less energy.
I would debate this, the black box abstraction provided by react, et al. would probably wipe out any performance benefit.
It's all in how you write the code. I've (as an end user) muddled through tons of slow react apps, and used some highly performance vanilla js (or just "framework-less") apps.
But you are right that it's mostly all down to how you write the code. But I'll gladly argue that it's a lot easier to write bad, inefficient UI code with vanilla JS than with React.
You don't really get to see the alternative because generally, react makes things so much easier and efficient that it opens a lot of doors and allows companies to go crazy with features and bloat. By being the beast it is, it puts a lot of power in the hands of developers, but equivalent UIs without react will most likely be 3 magnitudes worse. Keyword: equivalent.
More code leads to more cache misses. More code leads to more energy consumed transmitting that data over the internet, and wireless radios are energy-expensive. More code leads to more time parsing, compiling, optimizing, and then JITing code, which can utterly dominate actual runtime energy cost if the program is not long-lived - which describes a lot of webpages.
Finally, very few webpages actually need to even be a "moderately complex React/Vue/Svelte app" - the essential complexity to the task being done is low, and webdevs add extra, unnecessary features for very poor reasons (showing off?). Take https://nabeelqu.co/understanding for example - 1.17M downloaded for 21K of text and two small images (one of which didn't load anyway). There's a 276K JavaScript file in there, among others - and the primary purpose of this page is to display a static document. Or, take any modern newspaper website you want - bloated with images, tracking, and JavaScript providing near-useless (and probably near-unused) features with a data-size:content-size ratio of over 100. If something is moderately complex, it would be much better as a native app in the majority of situations, which comes with significant performance improvements.
console.log(0);The simplest code as you point out is often faster than the shortest.
There is a lot of negativity here on HN on the same things you mentioned, but I fail to see any viable alternatives.
Like what? Replace the MB of JS with plain Html and forms? It's not going to be simpler to code, and it's definitely not going to be simpler for the users. Or maybe use a native desktop app? Then it's even more complicated for the users, and coding it leads you in world of cross platform pain. And the closest thing there was to not using MB of Javascript and have decent UX was Java and applets/jlnp, but it somehow didn't manage to be widely adopted.
Programmers don't choose these things, because programmers aren't the real decision makers, it's management and business that makes the web awful.
I was talking mostly about the actual application logic and presentation.
BTW tracking is hapening even w/o javascript.
It is somewhat more complex to handle more pages in your code base, but each page is short and simple.
You end up with a lot of complexity around cookies/local storage (and trying to persuade users that cookies are not bad and that their virus checker should not delete the cookies please ...) or encoding the session ID in the URL and hoping that users do not share links or bookmark pages, and then of course you end up with the "please only click once" links around buttons etc.
You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language (although could be nodejs of course). It is an extra interface that needs to be designed and maintained with all the opportunities for screwups that come with it.
Those are things which developers do because they think it’s easier than learning the web standards or looks better on their résumé and as long as you avoid measuring actual performance you can sustain these beliefs for a long time even while your users are seeing performance below the level of a 2000s Rails app with worse error handling.
I am sorry, are you talking about example todo app ? because for most apps with complex navigation, data entry, and validation this is absolutely not true. Just use the DOM , might be somehow feasible with webcomponents, but they are years late to the game.
For IE11 just load polyfills and let the 2-10% of IE11 users pay the tax, instead of making all your users in modern browsers download giant bundles.
Youtube encodes the video only once, users decode them billions of times in their laptops/phones
Plus datacenters have an incentive to be energy efficient and are becoming more and more green.
My assumption always has been that Youtube is creating multiple renditions of videos at different resolutions and codecs.
I run without JS. If I need JS I start up a VM. It's quite common for eg. google groups to max out the CPU for 10 seconds or more before updating. This is where your problem is. A 100 million CPUs permanently at 100% is where your energy is going.
[0] I found this stat backed up here (https://www.brandwatch.com/blog/youtube-stats/) You should post this fact to stop other people wasting their time.
Over half of YouTube users use the site to work out how to do things they’ve not done before
This is one of the undersung advances of the web - it's become more than access to the worlds knowledge (like some uber library) but has become a new means of transmitting learning.
On the other side if one could workout a way to identify a product related to this "new thing to learn" the retargetting value would be huge
We can't change what's in the chair but we can change our product.
Feel-good savings are not helpful. You can do it but let's not pretend. Reminds me of an ex girlfriend that would account for coins she found on the ground in her monthly budget...
Where do you find enough coins on the ground for that? I haven't come across any in my entire life.
Just as a sort of thought about this, if the entire web moved to brotli over gzip, or if we introduced an even better compression algorithm that was widely distributed across the internet, what would that impact me? A 5% reduction in CPU usage for every computer loading every page? I'd be curious to hear what that would actually amount to, power-wise.
And then that PNG is loaded by a webpage, which contains no HTML, but loads 28 megabytes of JS, which your browser has to parse, JIT and run, and then that triggers loading of web-fonts, and after that we create a virtual DOM, and then render that into a real DOM... (which is probably around 150kb)
And then after about 15 seconds of 100% CPU time, the browser finally has something to show... And then it loads that minified PNG.
You know what? That PNG isn't the issue. That PNG probably has a highly optimized decoder, written in native code, and the relative cost of a optimized/unoptimized PNG in this case is probably 0.0001% of the total energy we just spent getting and rendering that page, a page which more often than not contains basically static content.
If that page instead:
1. had been plain, pre-rendered HTML
2. had no JS, except if needed.
3. had no web-fonts, because the user already has 2000 fonts installed. (And you want to be green, right?)
4. And finally had that PNG.
Then optimizing that PNG would actually have an impact. On most sites today though? Not a chance in a hell.
Also: that page would render in a nano-second, so it's not just a greenification, it's an actual real world performance-optimization too.
Look up Saudi Aramco, Chevron, Gasprom, Exxon, Coca Cola, Nestle, Bayer, JBS, Tyson etc. Many of them are owned by investors. Why can't we punish investors which are very few compared to the number of web developers out there?
It's like with taxing the wealthy. Everybody agrees the wealthier part of the population should be taxed more, but no one considers himself wealthy enough to fall in that category.
PEBCAK[0]
Personally, I still like to optimize my pages. I learned Web design, at a time when pages were supposed to be about 50KB, or less. That seems quaint, these days.
I use a lot of GIF and PNG8 images, and use CSS gradients and effects. I’ll do things like make a rollover image as a GIF in two parts, and use CSS to move the background image. Makes for a zippy rollover.
But I’m still beholden to my site framework or theme, loading 1MB of useless JS and CSS for every page. Some of the new site builders, using things like Jekyll, are nice, but take more time for me (I am not actually a Web designer, although I have written many, many Web sites).
As noted, the real hogs are on the big iron. We can write software and APIs to reduce CPU usage, but it’s a drop in the bucket, compared to the server. I think that server engineers are already doing everything they can to be efficient; simply because that confers a competitive advantage.
But, also as noted, as long as there’s a vast demand for cat videos, there will exist, a vast cat video delivery infrastructure.
If that is the case, then optimize for the user so they aren't running their car to charge their phone as often (or other such craziness).
My biggest problem with the article is the failure to quantify the energy use of these optimizations. Sure, it is difficult to do since there are so many variables and most of those variables are difficult to generalize. On the other hand, it should be possible to come up with relative measures to facilitate the optimization process. For example: when is it better to do something on the server vs. on the client? When will the decision even matter?
Of course, the suggestions offered by the article are also varied in quality. Some clearly offer better energy efficiency for both parties, such as not adding elements that you do not need. Others may indirectly benefit both parties: doing more server side processing on a popular website is going to benefit the consumer, but it also forces the provider to consider the cost of added overhead. Some simply have questionable merit, such as optimizing the size of resources that are infrequently used. Others are of dubious merit, such as the tendency of SEO to be used to find the provider's content rather than what the consumer needs.
It is a much more complex issue than can be addressed from a few quick tips.
I mean the articles not wrong, we should try and reduce the energy we use. But at the same time there's much more efficient ways to do so.
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.
"look you having to pay $xxxxxxx in PPC" because that low cost design agency messed up a site redesign.
Then don't they needs a new job? Thats not part of a developers job description.
To give an example from my fist job about two years in one morning my boss came in and dumped on my desk some exotic kit from Feranti that cost 2x my salary with the instructions
1 hook it up to the PDP 11 make it work 2 talk to Brian and write the code so he can use it on his 3d capture experiment.
My response was "cool"
- 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?
Any individual country implementing a carbon tax doesn't work because they put themselves at a big disadvantage, and goods and services go across country borders, taking with them almost-impossible to fairly calculate amounts of carbon.
The biggest things the world could do towards the "world dictator" approach would be:
* Have a consortium of countries implement a carbon tax, while taxing all inbound goods from countries that don't tax carbon.
* Adjust WTO rules to allow taxing imports based on estimated carbon content.
* Have the WTO decide which countries are "on track to meet carbon reduction targets". Allow taxes on imports from any country that isn't.
* Allow countries to "sue" another country for environmental damages. When they don't pay up, have a UN court able to threaten anything up to military action/takeover of the country's leadership to get payment.
I would think the invisible hand of the market would re-route all that pollution to areas without the tax and the earth wouldn't see that much difference. It's not like they're going to stop selling oil if the EU and US agree to stop burning so much of it.
I agree it's complex, but I think carbon taxes might be part of the complexity. If we're going to start messing about with markets, we should outright ban the offending activity and regulate harshly. If we're going to apply tokenomics to the problem and pretend we fixed it until we're too old to care, that seems worse somehow.
Or we can just do nothing and hope technology saves us. That's what the actual bet is whether we like it or not.
Diesel is not worse than petrol:
Diesel cars tend to have lower volumetric fuel consumption figures than comparable gasoline vehicles. However, the benefit in terms of CO2 emissions is significantly lower, as the combustion of 1 liter of diesel fuel releases approximately 13% more CO2 than for the same amount of gasoline.
https://www.theengineer.co.uk/fact-check-are-diesel-cars-rea...
But with a liter of diesel (usually) you can make more kms than with a liter of gasoline. I'm not sure the CO2/km of each class of motor, though
https://www.vox.com/2020/9/10/21430916/2020-presidential-ele...
Even policy makers struggle with this. It's very hard to make a comprehensive, understandable model that connects all the dots across the board. So, that's what this piece is about.
And here's the actual graph from the video:
The argument presented here isn't to reduce consumption - although, in absolute terms, that directly impacts carbon emissions - but to strategically replace fossil fuel sources for clean energy (solar, wind, water,...). It's an interesting perspective because it avoids turning the discussion about "consumption reduction" into a debate about token use cases such as "millions of web pages need to consume less energy."
To put it more succinctly, it's more interesting to consider the origin of the electricity coming out of the socket in a datacenter or housing then how it gets used by hardware plugged into those sockets.
I'll give you a for instance. Suppose you have to pick a host for your personal website and you're mindful about energy consumption. So, you're considering Digital Ocean: What type of energy is powering their datacenters? Turns out they don't really communicate about that, but intrepid users have figured it out (data februari 2020):
https://www.digitalocean.com/community/questions/what-kind-o...
So, if you choose NYC1 as your region when you pick a droplet, that's assumed to be powered by 100% wind energy.
Same with people who visit your website. Suppose, in some utopian way, 100% of your visitors have solar, batteries and are off the grid, then their daily visits to your website will have a reduced impact as well. Why reduced and not net-zero? Because the intermediate network infrastructure between NYC1 and, say, a visitor living in California, needs to be powered as well and there's no guarantee traffic won't be handled by fossil fuel powered network nodes at this point in time.
Why single them out?
Unlike a catalytic converter though, eventually (after 150,000km or so) they will become blocked up and cause a noticeable drop in power or cause engine fault codes. At that point you need to replace it, which could be a few thousand Euro for a new DPF, or the more common option is to remove it. This is illegal in most EU countries, but also a blind eye is turned to it - even in places with strict emissions checks like the UK.
AdBlue is a modern way of reducing this even more, but there are already devices you can buy that will trick the ECU into thinking your tank of AdBlue is full when its actually empty.
Combined with other common issues like injectors wearing out, as a diesel engine gets old it will burn fuel a lot dirtier than a similar aged petrol engine.
This is why cities produce more CO2 than rural areas. Potentially it is more efficient to live in a city but city dwellers are richer and hence spend and consume more.
I went to a talk by the economist Jeffrey Sachs a few years ago where he said the sustainable level of spending around the world was about $10K USD PPP. Not much room for a Tesla in that budget.
This one is highly misleading. They may produce some very specific pollution more than entire Europe together, but pollution overall will be clearly lower.
Emissions of just C02 is about 4000 megatonnes in just EU ( https://en.wikipedia.org/wiki/List_of_countries_by_carbon_di... )
4000 / 10 / 365 = 1.1 megatone per day.
I am not expert on ships, but emitting 1 100 000 000 t of C02 per day seems unlikely.
But developers continue to write inefficient code even if other consequences are obvious:
* If using cloud, often inefficient software will lead to higher expenses than developer time.
* On mobile devices battery life is important
* On mobile networks bundle sizes matter
Lack of knowledge of proper computer science fundamentals among blue collar developers is also a reason for this.
> "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
What is still missing to some degree is an admin panel for the clients to easily publish their own content, although there are some alternatives (Forestry, Netlify etc). So far my clients are happy to leave the actual content management to me, as their sites are only occasionally updated.
EDIT: Also, NUM looks really interesting!
Some people we've spoken to are interested in serving _very_ basic site content out of NUM records. So this could make the DNS your CMS which is interesting and terrifying in equal measure.
If that's what most users want and they want it bad enough to warrant a whole new protocol, then my thinking would be that it would have to provide some sort of competitive advantage. What has prevented it spreading despite this competitive advantage and why is that factor not present when it comes to adoption of your protocol?
Some businesses publish data using structured formats for the web (microdata, JSON-LD) but have not reached critical mass, other examples like .wellknown are for more technical use cases and are not that, errrr, well known.
> If that's what most users want and they want it bad enough to warrant a whole new protocol, then my thinking would be that it would have to provide some sort of competitive advantage.
Users want the data – they search Google (Knowledge Graph / Google Places) for it and scour websites for it – but there's no way for companies to provide the data directly to users, other than through websites. That's what NUM is – a way to do that.
> What has prevented it spreading despite this competitive advantage and why is that factor not present when it comes to adoption of your protocol?
It's the classic chicken and egg problem – no one stores data using method X because no one's looking for it using method X and no one's looking for data using method X because the data isn't there. We aim to overcome that by publishing millions of pieces of useful structured data to DNS.
We announced NUM on 1st September and it's experimental, so there's a long road ahead.
Most laypeople that choose Wordpress do so because they want some editing interface. The bloated Wordpress templates are a consequence of them looking good in ThemeForest. There's no incentive for template makers to make super fast 100%-static templates, as those don't attract attention.
But given the chance, site owners would replace their sites with whatever works. For instance, and a lot of local businesses where I don't have webpages anymore, but only Facebook profiles with a bunch of photos and text. Some of them even have custom domains that redirect to Facebook!
Apple App Clips in iOS 14 is something similar: you don't need an App for scooters or for buying Ice Cream, so I foresee some people moving to those just because it's cheaper to make... and because customers will probably be familiar with them.
I don't think most companies need a website, Facebook offers great tools to engage with customers but as a website it basically just lists key data. So all they really need a website for is to provide customers with key data.
Surely, not requiring me to register would be another way to make web more energy efficient. No?
I'm interested in NUM's approach though.
If you want to experiment with NUM then this page is the best starting point (and doesn't require login): https://app.numserver.com/tools/editor/add
We're due to publish a page to numserver.com that explains more about the service and allows you to experiment before requiring sign up.
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.
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.
You're right too. Most Cloud software is JVM based (Kafka, etc). I would be quite interested to see how more efficient things would be if they were ported to C++. Cassandra is a JVM-based NoSQL DB that has a C++ port called Scylla. Scylla destroys the JVM version.
And if you need more developer time is also a consumption of energy.
I think a more common problem is relying on general frameworks regardless of platform. Frameworks solves a general problem, but you solve a specific problem, as your example shows.
How much would it save to use SQL SELECT with the columns you need instead of a ORM that fetches everything?
Or what about API endpoints that deliveries everything to single page app that only needs a few values?
Most data deliveries online today is never used only to be discarded. And you have that discarding of data at two different places, between the database & the backend and then between the backend and the client. That is probably a higher cost than changing server language.
Quote myself "but you solve a specific problem, as your example shows."
So I have to assume your choice of technology for your problem was the correct one & the stats you supply seems to backup such claim.
However you also implying a bigger claim that C++, or something similar, is preferable in web development, where you mostly do string handling, is not something I can agree with.
I'm about a hundred percent certain that that's not at all how that works.
If downloading less (off page stuff) is important for a CLIENT device to do, it will do the lazy loading for you. If loading it or not matters the client will do so. (Anywhere that just pulls it all down is still going to do the same thing; since that's the easiest way when it doesn't matter.)
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
So, maybe, you should buy more RAM? :)
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.
The HTML specs define the div as the element of last resort, it has not been deleted from the spec but it really is supposed to be the last choice.
You can do it all with the new CSS Grid and pseudo elements, to never need a div. This does not mean swapping every div for a semantic element, defaulting to 'section' every time.
What I find sad is that the gurus of web design start blocking out their lorem ipsum examples with div elements. If they used real content they would be able to see what elements suited their content and use asides, navs, list items, figures and whatever else best suits.
Anyone preaching HTML and using div elements needs to be called out for it. There are no excuses, anything and everything can be refactored into sensible HTML that has a few classes and next to no div elements.
Time is the thing though. To refactor HTML to not use the mess of divs requires hard work, essentially it is a simplification of the code, actual real design which is not the same thing as decoration. Too often decoration is passed off as design whereas the innards of the page - the document structure and HTML - is essentially un-designed.
We are making artistic impressions of web pages and not the low carbon, well cached web pages we deserve.
Or are you referring to table vs. div from performance point of view? For that you can do your own testing. Create a DB, put in there 100k rows and then view them via a framework that uses the gazzilions I mentioned vs a table with 100k TR's. See for yourself which one loads faster. And to get out the loading times from DB, do it once then save it as HTML offline page for both tests and then use those pure HTML to load from local file. See that TABLE is faster.
I'm aware how to put together those benchmarks, but you're the person making the claim. The onus is on you to prove its faster, not me.
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.
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.
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?
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?
If you can shave x$/month from the infrastructure budget, wether it's servers or bandwith, you are being greener.
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.
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.
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.
[0]: https://www.sciencedirect.com/science/article/abs/pii/S22146...
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.
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!
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"
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...
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.
Nothing beats the feel of a static site loading in - so snappy and fast (especially if CSS has been adequately minified/bundled too).
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?
Is that a reason not to try to make things more efficient?
> There's just no way that "write less JavaScript" is the big needle mover compared to right sizing and scaling your fleet. Right?
My understanding is that it's less "write less JavaScript" and more "Don't pull in MB after MB of dependencies".
Also, that was just one of several points made by the author.
> Also, rather than spending two days optimizing all this, wouldn't you see much more carbon removed by spending two days planting trees?
Por que no los dos? As a result of the author having done so, it has now saved others who are interested in doing so time learning how.
Increasing efficiency has both a cost (how many hours did it take to improve this, and how much power was spent on competing to develop them) and and opportunity cost (what could we have spent those hours on instead). If the efficiency gain never repays the cost, you've actually made the system worse by making it more efficient.
There are no claims from the author about what is saved, it seems like the amount of energy spent reclaiming a small amount of energy will lately be worthwhile.
Probably good practice regardless. Recently saw a project with 23,000 lines of CSS thanks to pulling in library after library. That's just hard to reason about come maintenance time.
It's like spending an extra ten dollars once to save a tenth of a penny on each future tank of gas. Yes, there are times where that trade-off makes sense, but for most folks it won't actually make things better and could make them worse.
The author doesn't have any data to suggest what the savings here are. I assume these are miniscule or even immeasurable benefits that come at a very real cost in time and resources.
The world probably doesn't need my VM running 24/7 on the other hand. My server is in Singapore and in theory that means it's running on natural gas with Singapore getting 95% of it's power from natural gas. Better than coal, but still not great.
It's fun to think about how all this software manifests in real world, it's easy to pay it no attention.
You think these people will agree to optimize for energy savings? Not a chance, unfortunately.
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.
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).
* 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
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.
Experiment: most media sites are about 1 MB page loads, with iOS ad blockers on, it drops to 1 kB (three orders...)
https://theguardian.com/sustainable-business/2017/jul/10/100...
> “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.
He may have a valid point, but I’ll never find out as this attitude has turned me off finishing the article.
Or you could just route the entire Eastern Block and Russia off of Tier 1. That would literally solve the bot problem overnight and would drastically improve global operational security.
This is something we need to consider in the calculation.
And lets say all data centers would work completely "green" - wouldn't this discussion be obsolete?
- on ips displays, reduce dark greys in davor of black
- optimise Energy optimisations for different flavours of lcd
But I think there isn’t any straight forward browser API for that
At $dayjob we are A/B testing self-hosting every script; my suspicion is self-hosted ads will beat revenue from as networks even after paying for salesperson commissions.
No, seriously, do it now. Open your site with the "Network" tab open.
Make half of the lines go away.
I guarantee you that you can, often with trivial changes to your code.
Now do that again. That's going to be harder, but you're on a roll now, you can do it.
There you go. Done. You did it.
Not really that hard, was it?
Enthusiastically dragging windows around the desktop seemed to cause little spikes too which I assume is caused by my graphics card.
I know webpages I had to use for months that would eat my laptop battery if left alone (log in screen for a wifi network that scrolled the background, eating a full processor core and also search results page when using Firefox and Google).
I know, it probably wouldn't really work or have any effect, but it might be a fun little humorous side project.
Then optimized free-access content will rule.
React could be transferred ONCE to the browser-cache instead of hundreds of times.
Safari started this and Chrome is following - https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd...
So with a public JS CDN React would be still transferred multiple times.
Using a custom bundle is probably more efficient as it should compress better resulting in lower download sizes (bit often modern bundles are huge so I wouldn't rely on this point)
Does web loading time alone reduce the energy consumption?
Encouraging people to record every inane detail of their lives and hosting it must be a massive resource drain somewhere along the line.
I keep encountering blatantly wrong claims like "10 largest ships pollute more than entire Europe" or "unplugging unused chargers is important" or "there is no global warming" or "global warming threatens extinction of Homo Sapiens" so often that I stopped treating such claims seriously, unless there are proper verifiable nonpaywalled citations.
Around 10% of the world’s total electricity consumption is being used by the internet, according to a recent research report from Swedish KTH. [https://insidescandinavianbusiness.com/article.php?id=356]
Our best-case analysis shows a decline in consumption from 7.4% in 2012 to 6.9% of total global electricity consumption in 2017; however the worst-case shows a rise to 12.0% driven primarily by expansion of the network and data-center infrastructure. [https://aran.library.nuigalway.ie/xmlui/handle/10379/3563]
See figure (ICT electricity usage 2000kWh).[https://www.nature.com/articles/d41586-018-06610-y]
For shipping, bunker fuel emissions are modest in CO2, but high in particulates and extraordinarily high in S02 emissions. You can literally visually identify major shipping lane by such emissions, as here in the Indian Ocean:
https://earth.nullschool.net/#2020/09/18/1000Z/chem/surface/...
The thing is that there's a considerable set of commonly-tracked pollutants, with emissions varying greatly by source, as wwell as markedly different long-term and wide-are effects, some large, some small.
The chargers claim ... is mostly bullshit, however.
The claims may be both clickbait (misleading) and accurate (properly qualified).
The goal would then be to make websites as concise as possible, toss out all ads, comment sections, social media tie-ins, videos, needlessly long-winded articles, anything that slows the visit down, and kick the user out as soon as they have what they were searching for.
But capitalism doesn't approve of that.
Data centers are already mostly running on clean energy and in so far they are not, all big cloud providers have committed to being carbon neutral. So, if you have some solar on your roof, you basically could be browsing the web without expending any carbon. So, open some more tabs and stop worrying.
In any case, the web is a tiny portion of our overall energy consumption so it's not really worth prioritizing this for optimization. Best case, it won't make a lot of difference. Worst case you are sacrificing design and UX for something that ultimately doesn't matter in terms of tangible results.
Of course, there's nothing wrong with making laptop batteries last longer, making laptops run cooler, and delivering a web site that is fast and responsive.
It's fallacious, though. If you can save it later, you can save it sooner, and if it's worth saving at all, sooner is better. It's not an argument for a _solution_, it's an argument for _finding the will to implement the solution_ -- and it's the "minimally moral" argument for that. "Rather than do anything that takes moral strength, just make the problem worse and let other people deal with it!" The only worse stance is to no longer want a solution at all!
Of course it does seem like the real problem isn't figuring out what to do, but convincing people to care enough to do it. But our collective human intellect ought be able to do better than this.
I'm simply stating that increased demand for energy is currently being met (almost exclusively) through clean energy. Speeding that process up through more demand (which we have anyway) also speeds up the process of shutting down dirty capacity.
This is why coal is rapidly disappearing from most countries still operating coal plants. Unthinkable ten years ago, and yet nearly completed in some countries right now. Even the US is on a clear path to probably be completely coal free very soon.
The problem is not the demand but the dirty and expensive supply. I'm simply arguing to fix the supply problem by flooding the market with clean alternatives. The fastest way to do that is simply increase demand.
No. Historically, and globally, when electricity demand increases, electricity sources stack up. We may create more clean energy that way, and that will increase the percentage of renewables in the energy mix, but the atmosphere doesn't care about percentages. It cares about how many tonnes of carbon are released by the existing electricity sources that need to be shut down.
The last thing we need is another source for more electricity demand. Electrifying transportation alone will increase demand more than enough for your dream market investment magic.
The vast majority of new capacity on the grid is coming from wind and solar. As the supply of clean energy increases, suppliers actually decommission and shut down more expensive existing capacity. That's why coal plants are going out of business in lots of places and why some new gas plants are not utilized at 100% and instead kept around only to address peak demand. This is enabled by a growing demand for and a supply of clean electricity at a lower price than what they can produce with legacy plants.
Countries with growing economies tend to have a growing electricity market and a shrinking proportion of dirty energy. So, KWH goes up, CO2 goes down. The number of GWH from coal in Germany has actually gone down in recent years. While gas grew a little to offset that, much more growth came from re-newables. So, the CO2 production has been going down year on year. The amount of gas consumed per year in Germany is still substantial of course but not really growing at this point.
Accelerated growth in the energy market increases the pace at which energy providers invest in new capacity. This in turn speeds up the process of de-commissioning economically non viable plants.
Electrifying transport indeed adds a couple of tens of percent but it will take quite long to get there. If you drive 10000 miles in a year, that adds about 2.5GWH to your yearly energy bill (assuming 200 miles/50kwh of battery in your car). That's ~25% of the energy usage of an average house hold (in the US). But it will take quite some time before all households have EVs. 25% growth over 2 decades is not that much. Also a lot of that demand will be met by people putting solar on their own roofs, which technically shrinks the grid demand and overall energy market.