There is a lot of ongoing work in exploring ways to tie computing jobs to the times and places in the world where the electricity supply runs mostly on renewable energy. This is known as carbon-aware or carbon-responsive computing. But they tend to be extremely niche and small-scale with some notable exceptions I hope to cover in a later article.

There is however a caveat, which is seldom accounted for in the literature and messaging around carbon aware computing: powering your computing on renewable energy is not necessarily enough to reduce its CO2 emissions.

Counter-intuitively, to balance supply and demand, many national grids replace each additional unit of electricity demand from renewable sources with coal and natural gas equivalents. As a recent White House report on the Climate and Energy Implications of Crypto-Assets in the United States summarises it:

As the amount of renewable sources is held constant, but electricity demand increases, additional fossil power will likely be dispatched. This displacement results in no net change or in increases in total global emissions through a process called leakage.

So the renewable electricity consumed by your computing job, if it increases net electricity demand during "green hours" above the existing surplus energy, results in at least the same emissions as if it was powered by fossil fuels, since the grid will replace its additional energy demand with fossil fuels.

What's more, it is now understood that because of the leakage issue mentioned above, there is in fact not a one-to-one equivalence between fossil fuel energy and renewable energy emissions displacement, so you need extra renewable energy to displace the same amount of fossil fuel emissions. This means that swapping 1 terawatt of fossil fuel energy for 1 terawatt of renewable energy will not result in a 100% emissions displacement, so the like-for-like emissions of your "carbon-intelligent" computing job may still add up to net CO2 increases.

Consequently, there are only two ways to ensure that green computing powered by renewables would result in zero direct emissions on the main electricity grid:

• Using only surplus renewable electricity that would otherwise be curtailed by the grid.

• Constructing or contracting for new renewable electricity sources to power additional consumption from computing.

This is one key reason why within the field of carbon-aware computing research is underway on ways to target specifically stranded renewable energy, that is, energy that peaks when the sun decides to shine and clouds to part and winds to blow, at exactly the times when energy is not being consumed in sufficient volume by the grid. At those times the excess energy is not useable and could even lead to instability in the electricity grid, so it becomes curtailed and essentially thrown away and wasted. If we can target our computing jobs at that wasted renewable energy, we would help reduce digital emissions, stabilise the grid and avoid perverse effects from competing for a limited supply of available renewable energy with other users.

Most carbon-aware computing projects are cloud based, running their jobs on distributed cloud servers at times and places they happen to be powered by a preponderance of renewable energy in their respective electricity grids. Google in particular invested heavily in tracking the live energy mix across its global network of cloud servers and developing tools to predict and distribute its own computing jobs for minimal fossil fuel consumption. It then made those tools available to external users of its servers, enabling carbon computing at scale. It is not clear to me whether Google takes the emission displacement asymmetries into account in any area where it does not produce its own electricity, or whether targeting renewable-powered servers is in fact resulting in fossil fuel emissions from grid compensation protocols.

But this is not the only, or necessarily the best model for all use cases. An alternative, much less widely discussed model, is to directly co-locate one's servers with the renewable energy generation plants, and partner with electricity suppliers to use computing jobs to stabilise the grid. Bitcoin is at the cutting edge of this form of carbon-responsive computing, with several experiments at scale, and the green computing world would do well to learn from both its successes and its failures.

2. Renewable energy fluctuations and the electricity grid

To ensure the safe operation of the grid, voltage, frequency and similar electrical oscillations must be kept within specified ranges. This requires maintaining a constant balance of electricity supply and demand. If the balance is lost, blackouts, brownouts, and other grid disruptions can ensue. An increasing share of (unpredictably fluctuating) wind and solar energy in the electricity mix introduces unplanned peaks and drops. Whereas in legacy energy systems the amount of fossil fuel energy coming into the grid was under human control, and could therefore be stabilised on the supply side in a fully planned way. The more renewable energy is part of the mix, the more electricity generation (supply) is not under the control of humans and cannot adapt in a planned way to changes in electricity demand.

If every New Year's eve generates a predictable spike in electricity demand at night, under a fossil fuel-powered system, you simply "open the taps" and generate more electricity to meet demand and keep the grid on an even keel. In such a system, keeping demand and supply in balance is the job of the supply side, the people controlling the gas and coal electricity generators.

But in an electricity grid powered by solar and wind, you cannot simply will the wind or the sun to generate the planned energy spike at precisely 8 pm-2 am. In a grid powered by renewables, the only way to ensure that supply and demand are balanced is for electricity consumers to adapt to the rhythms of sun, water and wind. If consumers peak their demand when renewables are low, the grid could break. If renewables generate a sudden spike in supply when everyone is sleeping and companies are on holiday, that extra electricity will have to be dumped before it breaks the grid.

Clearly, it is hard to orchestrate an entire population to fit its rhythms to those of the natural elements, so electricity grid maintainers have created "demand response" programmes that pay companies to use electricity more intensely when consumer demand is not enough to spend the surplus renewable energy, and to stop all activity when consumer demand exceeds the available renewable electricity supply.

The more renewable energy powers the electricity grid as we advance in the energy transition, the more the need for demand-side stabilisation mechanisms.

3. Green computing as grid stabilisation tool: Bitcoin's Proof of Concept

Because computing can be electricity-intensive, because it can be located anywhere, and because it can be increased or diminished at will, it can be a great "load resource" for such demand response mechanisms, and Bitcoin has been the pioneer in harnessing this opportunity at scale as described in the previous post of this greening blockchains series.

I gave examples of grid participation schemes in Texas whereby Bitcoin miners are able to mine intensively (i.e. run intensive computing jobs) outside of peak times, and are paid by the tax-payer to stop mining/computing (and consuming electricity) when local grid demand is high. There are two types of such grid participation schemes around Bitcoin, reviewed in detail in a recent Masters' thesis:

• Bitcoin miners acting as "load resources" in conventional demand response programs, enabling them to participate in day-ahead markets. This helps with electricity demand, but does not guarantee that the energy mix powering Bitcoin mining is renewable. This is the larger share in the Texas experiment.

• Price-responsive Bitcoin mining, where miners are located behind-the-meter (BTM) directly at renewable power plants, mining when the market price for renewable electricity is low and refraining from mining when it is high. This green computing pattern is mostly based in West Texas, and this is the pattern that is most worthy of study by the wider green computing movement.

One crucial thing the Texas experience demonstrates is that with the right incentives, compute equipment can be co-located with renewable energy sources at scale, with miners flocking to Texas to carry out a gigantic amount of distributed computing powered exclusively by renewable energy. Close examination of the Texas model, introduced in my previous post, provides both some fantastic innovations to potentially emulate across distributed computing use cases, and also some extremely serious pitfalls to design for and avoid.

There is yet another complementary approach to carbon-aware computing that Bitcoin has made inroads on, and which have not been explored by the green computing movement. It involves linking distributed computing, such as Bitcoin's mining network, to the mostly off-grid, steadily growing distributed renewable power network (small-scale solar and wind generators in homes, offices, streets, fields and the like, and in some cases entire small-scale power plants).

The largest-scale experiment by far in using distributed electricity generation to power distributed computing was Bitcoin China between 2014-2021:

When the first group of bitcoin miners arrived in Sichuan around 2014, the sites they chose for bitcoin factories were near small hydropower stations that did not connect to the national power network... For the bitcoin miners, the power price of such offline stations is lower than the power price sold online... The arrival of the bitcoin factory ...made some small hydropower stations profitable.

Addiction to Power: Infrastructure and the making of Bitcoin mining zones in China and the United States

At its peak, China dominated 75% of the global Bitcoin mining infrastructure, and in the summer months when rain is plentiful, most of this eye-watering amount of distributed computing was powered by these small renewable hydroelectric plants. China’s winters are arid however, and solar and wind farms don’t produce a steady enough supply to run mining operations around the clock, so miners often turned to coal to compensate, negating any environmental gains from the summer. This put China's trajectory toward Net Zero in danger, leading, together with grid load and economic issues, to the 2021 crackdown that finally stopped the majority of Bitcoin mining in China.

Another variation on the use of distributed renewable energy generation to power distributed computing focuses on harnessing the surplus energy of even smaller-scale alternative energy providers, with one evocative proposal to use domestic solar generators to power distributed volunteer computing being floated by Nurminen et al. Bitcoin mining has innovated in this area too, with one promising approach being the company Soluna, in Morocco, which is researching how to finance off-grid renewable energy projects with Bitcoin mining.

Soluna's example, where off-grid projects are too small and too remote to be connected to and sell energy to the electricity grid, they can monetise their local renewable power generation via Bitcoin mining as a way of financing capacity growth until they can integrate into the national power grid. This is an interesting model, where renewable energy powers profitable computing, which in turn finances renewable energy expansion, allowing for more profitable computing. This is a model that could be applied to potentially much more meaningful and societally useful computing than Bitcoin mining.

4. Pitfalls of carbon aware computing at scale: lessons from Bitcoin

I pointed earlier to a dangerous blindspot in carbon-aware computing advocates, relating to the fact that simply switching to renewable energy does not necessarily reduce emissions. Perhaps an even bigger blindspot in the literature and messaging is that there is almost no acknowledgement that renewable energy currently powers only 13% of our global primary energy needs, and stranded renewable energy represents a tiny fraction of that. If all current Bitcoin usage targeted surplus renewable energy, let alone if every use case for carbon-aware computing did the same, the likelihood of perverse effects is high.

An example of such perverse effects could be price inflation. There is evidence from Texas, New York and China that where Bitcoin mining scales up in a locality, local consumer electricity costs also rise, meaning tax payers pay for both, the demand-response subsidies, and a "Bitcoin tax" on their bills. This would apply to any electricity intensive compute that took its place.

Another example of preverse effects is the way Bitcoin's electricity demand, as we saw in Texas, can place the grid under strain, renewable energy or not, attracting regulatory attention from Congress. In China too, pressures on the electricity grid led to regulatory warnings and interventions in 2019 that prefigured the final crackdown in 2021. In Venezuela, where subsidised electricity and economic collapse made Bitcoin a financial safe haven, Bitcoin mining spikes led to grid failures and blackouts with 90% of the country being without electric power for several hours, and whole regions losing access to electricity for an entire week. The economic, social and human impact in a country without a functioning social net, was immense.

5. Renewable electricity supply chains: blindspot of the green transition

Solar, wind and hydroelectric energy are, for all intents and purposes, endlessly renewable. But turbines, photovoltaic panels, lithium batteries and similar machinery needed to turn renewable energy into usable electricity rely on the extraction of minerals and metals that are not only not renewable, but too scarce to meet projected energy demand.

Failure to account for this is a blind-spot that extends beyond green computing to the green tech movement as a whole.

The results show that proven reserves and, in specific cases, resources of several metals are insufficient to build a renewable energy system at the predicted level of global energy demand by 2050...

We show here that even if the energy system was fully renewable, supply constraints on several elements other than carbon would still compel us to reduce our energy demand.

Enough Metals? Resource Constraints to Supply a Fully Renewable Energy System

Green energy is technically much greener than fossil fuel energy and therefore a key tool in our battle against climate change, but at scale, it is not altogether renewable: it merely shifts the supply chain challenges from fossil fuels to minerals and metals.

This is still preferable, minerals and metals, unlike fossil fuels, allowing for recycling and substitution, reducing overall emissions and improving energy resilience. But it is not a magic formula that spares us from the need to reduce our energy consumption. This means that running computing on renewables does not render its energy voraciousness moot, even in an all-renewable utopia.

6. Conclusion

There is so much to learn from some of the applications Bitcoin has pioneered at scale in the area of renewable energy, grid demand management and stranded energy distributed computing. Bitcoin's absolute social utility is debatable, as I discussed in a previous post. But its relative social utility is clearer: there are surely many more socially beneficial applications of computing, and the models of greener distributed computing pioneered by Bitcoin could be harnessed for such applications too.

As an example, there is an ongoing project aimed at discovering causal relationships among human genes to improve drug repositioning. Instead of running on a single supercomputer, it is distributing the compute task across a huge network grid of small computers, and has itself raised the possibility of being able to power this network from distributed renewable power generation, although not yet taken steps to make it happen.

If projects such as these, or other volunteer distributed computing projects could be repurposed to run as demand response mechanisms, the benefits could be planetary.

The challenge is economically incentivising such uses, although there are initiatives already offering potential Proof of Concept in the blockchain space, such as Gridcoin, Curecoin and Foldingcoin. A recent review of similar "added-value" innovations has identified an expansive horizon beyond Bitcoin's trudging consensus algorithms.

Beyond blockchains, mapping the socially beneficial computing use cases that would be an equally good fit, technically and commercially, for distributed power generation and grid participation implementations of carbon responsive computing, is itself an area of research ripe for exploration, which I believe can yield truly transformative fruits.

So what is the significance of Bitcoin's emissions? Is it catastrophic? Negligible? A powerful green tool in tackling climate change?

Environmental Bitcoin Myths

Before considering the merits of each claim, I want to look at examples of where these claims have gone beyond the evidence to become myths, as a way of highlighting the importance of questioning our own starting points, whatever they may be and seek evidence-based answers even if they turn out to be less conclusive or categorical than we might like.

Myth 1: Bitcoin as environmental catastrophe

One particularly impactful (and alarming) 2018 article in Nature was titled Bitcoin emissions alone could push global warming above 2°C, affirming a timeline of under 20 years, and 11 years in the worst-case scenario. Within months of its appearance, multiple peer-reviewed responses exposed fundamental flaws in the article's assumptions, and a recent methodological review of the field repeatedly used that article as an object lesson in quality gaps.

Nevertheless, that claim continues, as of 2023, to be cited by highly prominent voices like Greenpeace and Ben&Jerry's and even in recent academic literature.

Myth 2: Bitcoin as "Meh"

Bitcoin's own official environmental rationale is really an exercise in whataboutism, which argues there are many worse polluters, that metrics are hard, and that Bitcoin can be and sometimes is powered by renewable energy.

All this may be true, but it does not mean Bitcoin itself is not actually address the issue of whether Bitcoin is or is not in fact a significant source of pollution accelerating global warming.

Finally, Bitcoin argues that its ethical benefits outweigh its environmental costs, although it does not dedicate much effort to proving its case, and one senses it is more of a fig leaf than an earnest case being made. The rhetorical energy of their article is that the environmental concerns are ultimately negligible.

Myth 3: Bitcoin, green panacea

More emphatic than Bitcoin's own argument, even if building on arguments seeded in its article, is the unabashed environmental optimism of a widely syndicated post by Bitcoin lobbyist Dennis Porter, boldly titled: Bitcoin Mining Is Good for the Energy Grid and Good for the Environment.

The argument goes like this:

• There is a huge amount of unused (stranded) renewable energy being thrown away (curtailed) and going to waste.

• Sunshine and clouds are unpredictable, so solar energy might become suddenly available at times of very low domestic use, creating surpluses that cannot be stored, and therefore become stranded, and wasted.

• Because Bitcoin mining hardware can power down when energy is being consumed by the electricity grid, and power up when it is about to be curtailed, Bitcoin mining could run entirely on currently wasted renewable energy, switching off at peak times, meaning it wouldn't contribute new emissions.

• Bitcoin renewable electricity demand would generate financial incentives to accelerate investment in green electricity infrastructure, improving the electricity grid and accelerating the green energy transition.

• Additionally, methane (an acutely terrible greenhouse gas), is also regularly flared from landfills, abandoned wells, and oil and gas operations. Potter points out that such surplus methane could instead be turned into electricity to be consumed by co-located miners, turning Bitcoin into a carbon capture tool preventing the methane from getting trapped in the atmosphere.

On the face of it, Porter's article offers an excellent application of carbon-aware computing, and specifically time, demand and location shifting patterns. Such approaches are very much the cutting edge of current efforts to green the environmental impact of computing, and the Adora Foundation's Incubation Lab is supporting a range of fantastic carbon aware projects in this area, from machine learning to cloud computing, and from APIs to UI component libraries.

There are however a few caveats to this carbon-aware, energy-responsive, carbon-capturing Bitcoin utopia. The premise that Bitcoin could be good for the energy grid and good for the environment, even if accepted, does not support the title of the article, which claims that Bitcoin already is good for the energy grid and the environment.

Porter refers to an example of voluntary Bitcoin mining suspension at peak grid usage times in exchange for energy credits miners can redeem at non-peak times. This is part of a large scale experiment in using Bitcoin as a tool for grid stabilisation in the face of unpredictable renewable energy availability.

To ensure safe operation, voltage, frequency, and other electrical aspects of the grid must be kept within specified ranges. This requires a constant balance of electricity supply and demand. If the balance is lost, blackouts, brownouts, and other grid disruptions can ensue. An increasing share of wind and solar in the energy mix introduces unpredictable peaks and drops, so whereas in legacy energy systems the grid could be stabilised on the supply side in a planned way; the more renewable energy is part of the mix, the more you need demand to adapt to an ever changing supply to keep overall usage within the necessary ranges.

Porter's example is one such demand response solution, with Bitcoin being used to stabilise the grid. There are two types of such schemes:

• Price-responsive Bitcoin mining, where miners are located behind-the-meter (BTM) directly at renewable power plants, mining when the market price for renewable electricity is low and refraining from mining when it is high.

• Bitcoin miners acting as "load resources" in conventional demand response programs, enabling them to participate in day-ahead markets. This helps with electricity demand, but does not guarantee that the energy mix powering Bitcoin mining is renewable. Porter does not mention this dimension, which has the larger share in the Texas experiment.

Let us take a scenario where all miners operate in a price-responsive, renewable energy scheme. Even in this scenario, the Texas Bitcoin miners reduce peak time mining, but maximise non-peak time mining, adding to net energy demand overall, placing the entire grid under strain, raising electricity costs. These and other issues have led to an ongoing Cogressional investigation.

Which is to say, above and beyond the energy mix powering the grid, is the constantly growing energy demand. From this perspective, even if one were to grant Porter's most idyllic scenario, where Bitcoin is mined in an energy-aware manner, running mostly on otherwise wasted renewable energy, as long as net energy demand continues to grow, we face a host of negative consequences.

The strains and risks above have resulted in a permitting slowdown in the experiment that has choked the rate of Bitcoin expansion, while generating demand for new infrastructure investment, although not exlusively or primarily for green energy infrastructure.

The same kind of issues arise when considering Bitcoin as a methane emissions reduction mechanism.

Potter's methane combustion use case, building on research by ESG-oriented Bitcoin promoter Daniel Batten, also looks on the face of it like a promising carbon capture solution but it's very far from guaranteed. The White House's moderate stance on the subject rings true:

Crypto-asset mining that installs equipment to use vented methane to generate electricity for operations is more likely to help rather than hinder U.S. climate objectives. However, unless the CO2 is captured and stored, using vented methane at oil and gas wells will still generate CO2 emissions and contribute to climate change. Using vented or flared methane for crypto-asset mining must also be assessed against other uses for this methane, such as hydrogen production or transporting the methane via pipeline to end-users.

Climate and Energy Implications of Crypto-Assets in the United States

Environmentally minded Bitcoin miners could indeed adopt and adapt this approach with potentially beneficial impacts. Meanwhile, environmentally indifferent Bitcoin entrepreneurs don't have any intrinsic incentives to distinguish between green and non-green energy. Bitcoin mining could create perverse incentives that end up stimulating methane and flaring demand, such as intentionally flaring methane to earn rewards.

More generally, there is no Bitcoin-native reason for miners to limit themselves to stranded green energy, or in the case of methane and similar fossil fuel cases, to be sensitive to any environmental constraints. This has even meant that, in pursuit of cheap electricity, miners have gone as far as resurrecting previously shuttered fossil fuel plants for cheap electricity.

The gap between the green Bitcoin dream and its implementation at scale is not insignificant, and the challenges are not mentioned once in Porter's pitch.

Bitcoin's environmental impact: state of the evidence

Life Cycle Analysis (LCA) is the most commonly recommended approach for calculating environmental impacts and comprehensively estimating scopes 1-3 emissions.

This is particularly hard to do when it comes to Bitcoin because of the lack of observability of its highly decentralised network of mining equipment. There is accordingly vanishingly little research outside direct energy consumption studies of Bitcoin.

A Single Life Cycle Analysis of Bitcoin

There are no studies at all estimating Bitcoin's scopes 1-3 emissions, and only a single 2019 reference study by Kohler and Pizzol attempting a rather speculative Life Cycle Analysis of Bitcoin as a whole. The authors acknowledge the paucity of data and high levels of uncertainty and attempt to mitigate it via stochastic simulation and sensitivity analysis for all parameters.

This sole study estimates that the hardware production and end of life (EOL) stages of Bitcoin mining devices account for 0.932% and 0.025% of Bitcoin's emissions, respectively, with the preponderance of CO2 emissions pertaining to Bitcoin's use phase, that is, its mining activity.

Corroborating evidence for Kohler and Pizzol's model comes from a bottom-up Life Cycle Analysis of a single behind-the-metre Bitcoin mining operation at a gas-powered electricity plant in the USA. That study supported the 0.9% finding above for Bitcoin mining equipment production, plus 21% for the gas-based electricity production life cycle, and the remaining emissions pertaining to the use phase. This study did not look at end of life equipment stage, accepting Kohler and Pizzol's 0.025% figure and considering it negligible.

That tiny 0.025% of total emissions, even if considered accurate, should not be regarded as negligible. It obscures the magnitude and consequences of an estimated 30.7 metric kilotons of Bitcoin-related e-waste generated annually (as of 2021), potentially doubling at peak Bitcoin prices.

Blitcoin's electricity consumption: best estimate

The LCA studies above, preliminary though they are, suggest that the much more widespread direct energy and emissions estimates for Bitcoin may well furnish a credible ballpark, with a c. 1% addition from missing hardware manufacture and disposal attributions.

Of these direct energy estimates, the most credible "best guess" (and it is just that) is generally accepted to be the Cambridge Bitcoin Electricity Consumption Index (CBECI). CBECI over-estimates the prevalence of older, more polluting mining equipment, leading to likely over-estimates of electricity consumption. On the other hand, CBECI likely significantly over-estimates Power Usage Effectiveness (PUE) implausibly putting it on a par with best-in-class Google Data Centers and giving no evidence for its calculation. This would mean undercounting the power consumption.

Furthermore, CBECI estimates include life cycle emission factors for the various electricity generation technologies, but not for the manufacture and disposal of Bitcoin mining equipment, and therefore cannot be considered a Life Cycle Analysis (LCA) in their own right, as the authors themselves acknowledge.

One caveat in looking at the CBECI figures is that they represent credible ballparks for Bitcoin's current energy and carbon intensity, but caution should be exercised when projecting past rates into the future. Follow-up research by the authors of the 2019 LCA study modelled several future scenarios, showing Bitcoin's environmental impact could dramatically increase and dramatically reduce based on just 3 variables (with many more mentioned but unaccounted for), using the same Life Cycle Analysis model as the original 2019 study.

Having said that, these are the figures for Bitcoin's direct energy consumption:

• The CBECI estimates Bitcoin's annualised electricty consumption at 120 TWh.

• It also estimates Bitcoin's annualised greenhouse gas emissions at 60 metric tons of CO2.

Together with Kohler and Pizzol's 2019 LCA study, the CBECI could be used to make a start on scopes 1-3 estimates for Bitcoin, although this has yet to be undertaken. This would be a valuable area for future research.

Quantifying Bitcoin's electricity hunger: Proof-of-Work consensus as perverse incentive

Beyond any direct electricity consumption measure at any given time, assessing the significance of Bitcoin's environmental impact is linked to whether that consumption is likely to grow, remain constant, or diminish over time. From this perspective, the real environmental threat from Bitcoin is arguably not its energy consumption at any given time, but its constantly growing energy demand.

In Proof-of-Work consensus algorithms, energy voraciousness is a feature, not a bug. As one industry participant expressed it at Intel's recent Web3 and Sustainability consultation with various blockchain companies:

“We’re very concerned about digital assets like Bitcoin that are wasteful by design. The incentives baked into the code call for using more and more electricity, the more popular they become, not less and less.”

Web3 and Sustainability

Indeed, there are fundamental financial and security incentives baked into Proof of Work systems that make energy consumption an indicator of the blockchain's overall profitability and safety.

• As a bitcoin miner, the more mining equipment you deploy, the more energy you consume, and the greater your financial profits. There are moderating factors, but the principle holds.

• As an investor, the more computation is taking place in the network, the more energy is consumed, and the more secure your assets are.

Energy consumption is thus a simplified but powerful proxy for Bitcoin's overall profitability and security. Which explains why constant improvements to Bitcoin's energy efficiency have failed to diminish net electricity consumption and emissions. On the contrary, as mining hardware has become more and more energy efficient, energy consumption has grown in a pretty reciprocal curve.

This is to be expected. In a system as heavily incentivised as Bitcoin, efficiency gains make possible more mining and more computation for the same electricity. Instead of electricity diminishing to stay within previous usage electricity demand grows to achieve more consumption for the same price, leading to increased total emissions, a rebound effect known as Jevon's Paradox.

How significant is Bitcoin's environmental impact?

The facts are clear. At approximately 120 TWh and 60 MtCO2e, per year Bitcoin is environmentally costly. More so than its most ardent evangelists would claim, less so than its most ardent detractors would warn.

The following comparison by the CBECI authors is illustrative:

The Bitcoin's electricity consumption worldwide is roughly equivalent to that of all fridges in the USA, with a lower carbon footprint, given the embodied carbon of fridges is much higher than that of Bitcoin miners. Taking the mining analogy literally, the authors further make the point that global Bitcoin mining is roughly equivalent to the 130TWh consumed by global gold mining.

I think the closest like for like comparison might be data center usage, as both are computing-focused operations, and both show similar incentives. Sticking to the CBECI comparison for consistency, Bitcoin's total electricity use is equivalent to c. 60% of the global electricity consumption of data centres.

On the one hand, data centres power hundreds of times more applications and utilities than Bitcoin's much narrower uses, so one could argue that the amount of electricity consumption used for the amount of utility gained, shows Bitcoin in a very unfavourable light.

On the other hand, and for the exact same reason, data centers' scope 3 emissions are dramatically greater, since so many energy consuming tools would be inconceivable without them. The state of the art research by Freitag et al, notes an approximate research consensus on emissions from data centers at approximately 130 MtCO2e. They do go on to suggest this is an under-estimate truncating elements of the supply chain, but that's a topic for another post.

If we take CBCI's much less rigorous emissions estimates as broadly credible, that would mean that while data centers consume 40% more electricity than Bitcoin, they generate 200% more CO2 emissions than Bitcoin. We are not in fact comparing like with like, given that CBCI's estimates are not life cycle analyses, but given we have already established a likely addition of 1% from life cycle assessments, the numbers do remain broadly comparable pending more rigorous LCA research into Bitcoin. From this perspective Bitcoin, while arguably less useful, is also less polluting than data centers in the round.

Less commonly discussed are environmental impacts beyond CO2. As the most recent White House report on the climate implications of crypto-assets in the United States summarises:

Besides purchased grid electricity, crypto-asset mining operations can also cause local noise and water impacts, electronic waste, air and other pollution from any direct usage of fossil-fired electricity, and additional air, water, and waste impacts associated with all grid electricity usage. These local impacts can exacerbate environmental justice issues for neighboring communities, which are often already burdened with other pollutants, heat, traffic, or noise.

Climate and Energy Implications of Crypto-Assets in the United States

Is Bitcoin an environmental catastrophe?

Judging the significance of Bitcoin's emissions

Currently, no, it is not. Turning this time to CBECI's comparison of CO2 emissions:

60 million tonnes of CO2 is not nothing. It is equivalent to putting 13 million petrol cars on the road for a year, or (fun fact) every car in Nigeria. More painfully, using the Mortality Cost of Carbon measure, it would be accountable, in 2022 alone, for some 13,500 deaths from its causal share of extreme heat events due to global warming, by 2100. We cannot therefore dismiss Bitcoin's environmental impacts as negligible. They are in fact grave.

But in the context of other technology uses, it is nowhere near comparable to the alarm caused by many more damaging digital industries and tools. As highlighted in the comparison above, US video games, in the sole study devoted to the subject, have been estimated to be responsible for 24 million tonnes of CO2 emissions. The US accounts for less than 20% of the global gaming industry. We have no actual research on the global carbon footprint of gaming, but taking US numbers as indicative of the whole, we can roughly say that video games globally emit nearly double the CO2 emissions of Bitcoin, while evoking less than 1% of the environmental panic.

If the question however is framed in terms of its potential and likelihood of becoming environmentally catastrophic in the near term, the answer becomes more complicated. Bitcoin's electricity consumption has grown by 137% in the last 5 years, or an average of 27% per year. In a linear trajectory, that would mean Bitcoin's electricity consumption and associated emissions would double roughly every 4 years, a dangerously compounding effect in the face of accelerating global warming.

But as emphasised earlier, Bitcoin's electricity consumption cannot be approached in linear terms. In the wake of the well-documented crypto crisis, Bitcoin's electricity consumption rose by 3% in 2022, whereas in 2021 it rose by 53%. The 27% average is clearly unreliable, if not meaningless.

Pizol et al modelled 4 scenarios for Bitcoin's future Global Warming Impact:

• a linear (business as usual) scenario.

• a location-sensitive scenario where new mining facilities are only installed in more competitive places with lower energy prices. The Global Warming Impact rose by 31%

• an equipment-sensitive scenario, where only more efficient mining equipment was used in new bitcoin mining projects. The Global Warming Impact decreased by 48%

• a scenario where new bitcoin projects grew only in cheaper locations while using only the latest, more efficient mining equipment. The Global Warming Impact decreased by 32%

This was used to illustrate how misleading it can be to create linear prediction models, where Bitcoin network growth equates to emissions growth in a constant manner. There are scenarios where Bitcoin network growth could result in both dramatically greater negative impacts, but also dramatically greener overall impacts. The model does not account for Bitcoin's huge sensitivity to non-environmental factors, like national regulatory climate, which would affect mining location and hence emissions; massive Bitcoin price fluctuations, and their impact on demand, etc.

In fact, the price of Bitcoin tracks most closely to its energy demand, reinforcing the correlation between profitability, security and energy consumption. One recent study systematically assessed the link between demand for Bitcoin (which translates to Bitcoin price) and environmental degradation, and found that the link was statistically causal. A further study took a different approach to assess the correlations between Bitcoin market conditions and Bitcoin energy consumption, and likewise found an unmistakable correlation.

This suggests that our prediction of the long term magnitude of Bitcoin's environmental impact is likely to align with our assessment of its long term financial prospects. If we are bullish about its economic viability, we are bearish about its environmental impact; if we are bearish about its financial prospects, we are bullish about its environmental impact, in a pretty linear fashion.

Mining equipment efficiency gains have been touted as a moderating factor, but the last century of hardware efficiency improvements across ICT is a pretty strong predictor of likely rebound effects, meaning that, in a Proof-of-Work system like Bitcoin, I don't believe hardware improvements will likely result in net environmental gains, and could well result in accelerated net emissions.

Which is to say:

• If you believe Bitcoin will be massively successful, massively adopted, and transform the way society structures its financial life and much beside... then yes, Bitcoin is likely poised to be environmentally catastrophic.

• If you believe Bitcoin is an over-hyped artefact of the pilot stage of blockchain innovation, a gambler's dream (or addiction) that will be left behind by different, better tech and future regulation, then Bitcoin is indeed a massive, painful, costly environmental waste: but not an environmental disaster.

• If you think the answer lies between, for instance predicting that the cycle of peaks and troths will continue, and that it may eventually be left behind, but that it won't be quick, and it will probably be much bigger by then: then Bitcoin merits serious worry and environmental advocacy, within the Bitcoin community and in the regulatory sphere.

Is Bitcoin worth the environmental impact?

This is a question Bitcoin itself is not afraid to ask, answering in the affirmative. But it does not really try very hard to make its case, barely going through the motions by adducing in evidence Bitcoin's provision of some banking-type services to an unquantified proportion of the unbanked of the world and its contribution to SDG target 10.c to reduce the cost of international remittances.

Hardly a ringing justification for its attributable ~13,000 deaths a year from accelerating climate change. One could argue that Bitcoin's two cited contributions provide more societal value than say, the video-game industry, whose environmental footprint is likely much higher. Or one could got further and point to the tobacco industry's annual emissions of 84 million tons of CO2 for delivering social harm at scale. But such examples are only useful as fodder for whataboutism. They say precisely nothing as to ethical, let alone environmental justifications for mining, or investing, in Bitcoin itself.

Elaborating on the above, the ethical case for Bitcoin as discussed by its advocates may be summarised as follows:

• Financial inclusion: Bitcoin can provide a way for individuals who do not have access to traditional banking and financial services to participate in the global economy. By enabling peer-to-peer transactions without the need for a financial intermediary, Bitcoin can provide greater financial inclusion and access for marginalized communities. It can help reduce the cost and complexity of international remittances, which are a critical source of income for many people in developing countries. Bitcoin can also enable micropayments which are not economically feasible with traditional payment systems. This has implications in contexts of extreme poverty or financial exclusion while opening up new opportunities for monetisation and revenue streams in the informal economy and sectors like the arts.

• Financial stability, resilience and recovery: Bitcoin shares many of the same characteristics as gold, such as scarcity, durability, and divisibility, so it can provide a store of value that is resistant to inflation and economic volatility. This has led to its widespread use in contexts of mainstream financial collapse, as a hedge and safe haven.

• Financial freedom and autonomy: as a decentralized digital currency Bitcoin operates independently of traditional financial systems and government control. This independence and decentralization can in theory provide a greater degree of financial autonomy for individuals and communities, and help to protect against censorship and government interference.

• Incentivising the green transition: Bitcoin mining can provide an economic incentive for investment in renewable energy sources, such as solar or wind power, which can help to reduce greenhouse gas emissions and promote sustainability. It can help address the issue of massive renewable energy curtailment and waste, mitigate impacts of fossil fuel generation, and be deployed as a carbon capture mechanism. As summarised by Daniel Batten:

• 

As we have seen already, there are many nuances to each of these claims, but for the sake of argument, let us grant every one of the above benefits. If one could moderate or exclude fossil-fuel-powered Bitcoin mining, ensuring Bitcoin mining runs on surplus renewable energy, or leverages non-residual renewable energy to grow net renewable energy capacity for large ultimate environmental rewards, Bitcoin could be a laudably green technology.

What is clear is that this is not primarily a technological issue. The technical means exist or can be realistically developed to run Bitcoin at scale on renewable power. But this is impossible without concerted government action in the form of well-honed incentive mechanisms to make green approaches to Bitcoin mining profitable and expand renewable energy capacity; and enforceable regulation that curbs, disincentivises or impedes fossil-fuel-powered Bitcoin mining. And there is no evidence of this regulatory combination happening anywhere on a national scale.

There is at least, scope for regulatory advocacy and experimentation by green-minded Bitcoin advocates.

The question arises: is Bitcoin the best way to achieve these outcomes?

There are a host of blockchain alternatives, which are delivering or could deliver the very same goals. There are also non-blockchain alternatives that could step into use cases pioneered by Bitcoin, such as grid-participation for carbon-aware computing as a demand response mechanism. So granted the above ethical benefits, why Bitcoin and not some alternative?

On the side of Bitcoin, it is far bigger than all the blockchain alternatives in terms of market capitalization, trading volume, and overall brand recognition. This means its potential for network effects, and therefore for achieving the goals above at scale and at speed could be greater, even much greater, than its competitors. Investing in growing Bitcoin as a means of delivering on the objectives above could lead to greater positive impacts faster.

But this is an argument that only holds if the alternatives have a similar benefit/waste/risk profile.

In fact, Ethereum, to give just one example, can approximate most of Bitcoin's key justifications above, although, with less scarcity and higher transaction costs, it may be less compelling than Bitcoin as a value store or financial inclusion mechanism. But unlike Bitcoin, Ethereum is designed as a software building platform, in addition to its functionality as a crypto currency. This means that its potential beneficial uses include but go well, well beyond Bitcoin's financial focus.

It is true that there are mechanisms now for building dapps on top of Bitcoin, but this is not a use case that has reached scale, or is natively suited to Bitcoin, unlike Ethereum and many more alternatives. However, it is entirely within the realm of possibility for this dimension to expand within the Bitcoin ecosystem, and take advantage of the much greater network effects.

More significant is the fact that Ethereum has moved from a Proof-of-Work to a Proof-of-Stake consensus algorithm, dramatically reducing Ethereum's energy intensity compared to Bitcoin, so that roughly similar benefits could be achieved for a fraction of the energy costs, and more importantly, without comparable perverse incentives toward energy consumption and demand, or the overwhelmingly wasteful computation.

This latter point is even more significant outside the blockchain. Bitcoin has pioneered compelling models for using computation to consume stranded renewable energy and serve as a demand response solution to growing grid instability from intermittent renewable power supply. But the compute itself is almost entirely pointless, described as a puzzle saving game in which most attempts amount to nothing. And as we have established, it brings with it an intrinsic energy voraciousness whose risks and consequences do not go away when powered by renewables.

What if that same compute time was devoted, not to hashing algorithms, but to societally meaningful computing problems, and did not imply an inseparable link between profitability, security and energy consumption?

So is Bitcoin worth the environmental impact?

In a rare and unlikely scenario where all its potential ethical benefits are being harnessed, and its very serious risks and costs mitigated, one could definitely make the case for Bitcoin's ongoing use and expansion, or at the very least, place it much, much lower in the priority industries to address from an environmental standpoint. But even in this idyllic setting, it seems unlikely that Bitcoin is worth its environmental impacts in comparison to alternative technologies.

When taking all factors into account, the only advantage of Bitcoin is its first-mover advantage and market dominance, enabling greater scale and faster expansion through network effects. But this becomes a massive liability in the likely prevalence of Bitcoin implementations in which negative societal impacts match or exceed positive ones.

Conclusion

In closing, we can derive four key insights from the current state of the art:

1. Bitcoin is not currently the environmental catastrophe its most vociferous detractors portray.

2. It is nevertheless environmentally costly and seriously impactful; carries perverse incentives that hardwire energy hunger into its model in an unsustainable way that is not solved by renewables; dedicates almost all its electricity to wasteful computation; and is a poorer instrument in the round to achieve its recognised potential societal benefits than many existing alternatives.

3. This should not blind us to the value of Bitcoin's innovations in the area of carbon-aware computing and methane carbon capture at scale, and its current potential, in circumscribed and carefully designed implementations, to advance the environmental agenda in specific local contexts.

4. Bitcoin can serve, within these very narrow parameters, as a design template that could be adopted and adapted by better, more beneficial and less harmful technologies that can substitute and enhance Bitcoin's current positive applications.

But my own concerns in this series are more immediate, and more urgent. Because the Internet, the collective machine that powers the Web, is also among the most environmentally destructive inventions in the world today. If WordPress really occupies a significant part of the Internet, it would mean it has a notable role to play in our battle against climate change - as an ally or an obstacle.

To no one's surprise, arriving at reliable, or simply evidence based estimates, is no easy task.

Wordpress: 40% of the Web?

The official WordPress.org website celebrates "powering 40% of the web". This figure is ubiquitous whenever WordPress is discussed as a platform.

The 40% quoted by WordPress.org comes from W3Techs calculations. It is a carefully calculated estimate with a transparent methodology, so, as long as we are clear about what is being measured, WordPress.org is justified in quoting it.

The W3Techs percentages are drawn from a targeted pool of the top 10 million websites as indexed by Alexa. They justify this by the assumption that these are all real active websites, whereas beyond this number there are a large number of dead or bot populated websites which should not be counted.

Alexa has been retired as a website, and it's unclear what future estimates will be based on, and how comparable they are, but for now Alexa persists as an API until the end of 2023 so these numbers can be run for one more year.

That means that to be more accurate, WordPress.org should say "powering 40% of the top 10 million websites". As discussed in my previous post on the size of the Worldwide Web, I estimate there are 350 million resolvable websites, and the likely number of non-spam, active WordPress websites is, as we shall see, much higher than 10 million.

This does not invalidate the value of the W3Techs metrics, because they are clear about what they cover and have a clear rationale and evidence base. What it does make clear however is that the claim that WordPress runs in 40% of the Worldwide Web an overstatement.

455 million WordPress websites?

Although not officially quoted by WordPress.org, the figure of 455 million WordPress sites is quoted very frequently in recent websites discussing WordPress stats

One indicative example states:

There are currently over 455 million sites that use WordPress.

Yes, that’s not a typo; the number is 455 with six zeroes.

Where do these numbers come from?

I have not been able to find the original source of this claim, but I have been able to track it at least as far back as December 2020, when the Internet Archive has a record of a secjuice blog stating:

According to Netcraft, 1.3 billion websites exist to date, of which 35% (roughly 455 million) are on WordPress.

We can see from this and other 2020 blogs that 1.3 billion website figure comes from the January 2020 Netcraft Server Survey. This was already a misunderstanding of the numbers, when in reality, the Netcraft survey estimated the number of active websites at a fraction of that (c. 2 million), with the rest of the web (adding up to the 1.3 billion) considered "dead" by them. I cover this in my blog post on the size of the Web.

While the 35% figure comes, as I noted, originally from W3techs.com. The 455 million WordPress websites is the result of applying the W3techs percentage to Netcraft's 1.3 billion gross number (active and inactive).

The problem is that this involves comparing apples and pears, amounting to a sampling error of more than 10,000% (40% of 10 million vs 40% of 1 billion)!

4 million of the highest ranking WordPress websites is still hugely impressive and impactful, but it is orders of magnitude less than 455 million WordPress websites. This misunderstanding (well beyond conventional frippery) has memefied and become even more de-anchored from fact as time has gone on. Both the Netcraft numbers and the W3Techs percentages have changed in the years since the 455 million figure was coined, but the number 455 million number remains constant, and cascades through the marketing claims of secondary products. As an example, a WordPress plugin claimed in May 2022 that Dogecoin (because of course) can now be accepted by 455 million websites:

For anyone reading this post, it should be clear that the estimate of 455 million WordPress websites should be consigned to the bonfire of the vanities.

Best estimate

While the methodology used by W3Techs has its merits, and is a good marketing stat, it is not the best approach available.

I have covered the (somewhat opaque) methodology of Builtwith.com in my previous post. Their extensive automated mapping of the web, which, unlike the Alexa ranking, does not aim for most popular only but instead attempts 100% automated coverage of live sites, detects 36 million active WordPress websites as of October 2022. It also ambiguously cites 60 million "websites that are WordPress customers", which I take to mean websites that have historically been detected as using WordPress, 24 million of which have moved on to other technologies (BuiltWith gives you both current and historic technology uses).

There are a number of BuiltWith alternatives, but they mostly seem to have a much more limited scanning range and come up with much smaller numbers (as of October 2022):

W3Techs detects 4 million websites.

Wappalyser detects 5 million WordPress sites.

WhatCMS detects 6 million websites.

Similar Tech detects 7 million sites.

Hunter detects 12 million sites.

Rescan is possibly the closest to BuiltWith, and detects 17 million domains, which it conflates with websites, whereas other trackers distinguish between the two, as a single domain could include a huge number of websites in its subdomains.

From this review we can infer that the lower estimates (4-7 million websites) likely use a methodology similar to W3Techs, using a ranked subset (e.g. Alexa rank, Google PageRank rank, Page authority).

Mid estimates (12-17 million) likely rely on domain scanning.

High estimates like BuiltWith's (36 million) likely rely on comprehensive, though not exhaustive, IPV4 port scanning, and are likely the most accurate.

What percentage of the Web runs WordPress?

A recap of my conclusions regarding the size of the Worldwide Web is as follows:

Triangulating the datapoints from Netcraft, Internet Live Stats, BuiltWith, Domainnamesstat and Cesys, this is my own best estimate:

• 1.9 billion internet services running on IPv4 addresses

• 706 million hosts (200 million physical, 406 million virtual)

• 614 million registered domains

• 350 million resolvable domains (active websites)

Accordingly, adopting the BuiltWith numbers as the best-in-class estimate of live WordPress websites, WordPress accounts for an estimated 10% of all websites.

However these 350 million websites are not all part of what W3Techs fairly and usefully designates "the meaningful web".

In their own analysis of Alexa ranked websites, which by the numbers above represent the top 3% of all websites, a full half a million (5% of their sample) are "meaningless" websites ("this works", "hello world", bot generated word salads).

Given their sample represents the very top of the active web pyramid, it is reasonable to surmise that the more you approach the base of the remaining 97% of the popularity pyramid, the higher the percentage of the meaningless web will be.

The actual proportion of "the meaningful web" running WordPress is likely to be higher than 10% given the likely ratio of meaningful/meaningless websites in the totality of websites; and lower than 40%, given the nearly 10 times higher number of total sites compared to the Alexa ranked sample, the overwhelming majority with vastly less traffic and complexity than the top 3%.

We can perhaps further narrow the range by looking at an alternative but similar methodology to that used by W3Techs to arrive at 40%. The Web Almanac report by HTTP Archive looked at the 8 million websites in the Google Chrome UX Report dataset, which akin to Alexa is based on Google's top 10 million most popular websites (the 2 million discrepancy is not explained but may reflect minimum popularity and indexability requirements).

Google arrives at a 35% of the most popular sites running on WordPress.

It is impossible to get more precision than 10-35% of all meaningful websites run WordPress, but perhaps a median of 22% is not unreasonable.

This is half the standard 40% claim, but it is still huge to say WordPress powers approximately 1 in 5 real websites on the planet.

Conclusion

Taking the above findings we can conclude that:

• A significant, as yet unquantified proportion of the 350 million active websites are meaningless placeholders or spam, constituting "the meaningless web".

• If we take the size of the "meaningless web" to be around c.50%, 175 million websites, or around half the "active web", there are approximately 38 million active WordPress websites, accounting for (very) roughly 1 in 5 (22%) of meaningful websites in the world.

The reason I am interested however, is that having a sense of how big the Web is provides an important benchmark for estimating the environmental footprint of the Internet, and understand what priority to give to reducing its emissions.

Behind the numbers

There are a number of figures floating around, often without citations, and where backed by references, without any discussion or examination of the methodologies involved. Here I review the main sources of estimates, and how each arrives at a number.

Netcraft

Perhaps the most widely cited number comes from a company called Netcraft. Their exact methodology and tooling is not, as far as I can tell, fully public, but we can deduce that it relies on scanning of the IPv4 space, almost certainly using the standard approach of sending a TCP SYN packet to, for instance, port 80. If the port is closed, the host responds with an RST packet. If the port is open, the host responds with a TCP SYN/ACK packet indicating that a connection can be established. Put another way, Netcraft sends a signal to knock on the door of every Internet address, and logs every time someone shouts "coming!".

So according to Netcraft, out of all the IP addresses polled this way, 1.1 billion established a connection, indicating a website host in operation.

There are two problems with this.

1) Netcraft indicates that "The number of hosts found running internet web sites by the Web Server Survey is large (over 1.1 billion hostnames), but not exhaustive."

This suggests that it does not poll the entire IPv4 space, so the actual number of total open hosts is likely to be higher.

Internet Live Stats

This may explain why Internet Live Stats, an equally opaque (as regards specific methods and data sources), but equally authoritative Internet-wide counter (cited by W3C and by Tim Berners-Lee among others) has instead found as of August 2022, 1.9 billion websites, or nearly double the current Netcraft figure.

This higher figure is apparently arrived at by integrating a range of data sources (including Netcraft Server Surveys) and projecting second by second estimates using a proprietary [worldometers algorithm (https://www.worldometers.info/about/)]. So again, not an exact or comprehensive number, but rather a projection building using undisclosed assumptions and methods atop Netcraft's original numbers.

Hosts vs websites

The numbers above have to be caveated further by the fact that open named hosts do not translate into actually active websites. So the 1-2 billion hosts detected should certainly be counted when estimating the size of the Internet, but not when estimating the size of the Web, which is the corner of the Internet populated by websites.

Netcraft estimates that out of the 1.1 billion sites detected, only 200 million sites can be considered active.

Internet Live Stats likewise estimated the number of active websites at less that 200 million. The figure is likely derived from Netcraft itself, and suggests that 70-85% of the web is populated by dead or placeholder websites.

Builtwith.com

Builtwith.com offers a third estimation of the number of websites, again without full transparency as to actual methodology.

BuiltWith affirm that they have 100% coverage of the web, meaning "domains and subdomains" using "technology under patent", and arrive at a mysterious figure of 16.4 billion potential websites. This would be 6 times more than Netcraft's estimates.

Specifically, they assert their coverage included "100% .com/.net/.org & 100% active website coverage". This is not particularly clear or helpful. Instead of their headline claim to cover 100% of the web, in reality they appear to mean 100% of those 3 Top Level Domains plus all websites defined as active.

I can't tell how that could translate into a 16.4 billion figure, given there are 4.3 billion IPv4 addresses, 614 million registered domains, and 37 (characters allowed) to the power of 63 (maximum characters allowed) potential domain names per TLD, which comes to a 6 followed by 98 zeros, so a lot more than 16.4 billion. Alternatively, there are 189 million domains registered in the .com, .net and .org tlds in August 2022. Each domain can have up to 500 subdomains, but that makes the potential pool 90 billion, not 16.4. It could be that the figure estimates the potential number of virtual hosts for registered domains, or the maximum capacity of detected computers but it's impossible to know.

Similarly, they arrive at a hard to validate figure of 673 million active websites, defined as domains which are not "parked". This is more than 3 times the Netcraft and Internet Live Stats estimates. Given that it is estimated that around 70% of domains are parked, it seems questionable for BuiltWith to arrive at more active websites than registered domains.

A more reliable and transparent BuiltWith metric is their total number of websites detected, which stands at 557 million as of August 2022. This is closer in line with the 614 million registered domains. Of these, 34.5% (nearly 200 million websites), cannot resolve the domain, taking down the number to 350 million active websites.

Again, it's not immediately clear how these much more realistic figures, clearly based on actual IP scanning, correlate to the apparently untethered figures given earlier.

Censys

Probably the most reliable, and certainly the most transparent estimate of the size of the active web can be arrived at via Censys, which uses zmap to carry out Internet wide scans of the entire IPv4 space. Its methodology and code are fully open source, and backed by a large body of academic research and tooling extensions. Censys detects 1.9 billion services, 222.5 million hosts and 484.1 million virtual hosts as of August 2022.

This aligns much more closely to the 1.9 billion figure from Internet Live Stats quoted above, and the 225 million active hosts is likewise in range for both Internet Live Stats and Netcraft for what they call "active websites". The Netcraft/Internet Live Stats figure is likely an undercount ignoring virtual hosts: once you add these, the total rises to 706.6 million hosts which is in range of the 614 million registered domains. The extra 90 million likely reflects that Censys scans ports beyond those assigned to http and https, so may detect services beyond the surface web.

So how big is the Web?

Triangulating the datapoints from Netcraft, Internet Live Stats, BuiltWith, Domainnamesstat and Cesys, this is my own best estimate:

• 1.9 billion internet services running on IPv4 addresses
• 706 million hosts (200 million physical, 406 million virtual)
• 614 million registered domains
• 350 million resolvable domains (active websites)

So the active Worldwide Web can be said to contain 350 million websites. This is probably the best benchmark to use when estimating the size and impact of the web.

Watch this space for future posts building on this!

Software, with all its wonderful conveniences and indulgences, drives the manufacture of ever newer gadgets, which includes the extraction of precious and rare metals from the earth, often in conflict zones, and with tremendous ecological and social impact.

Software too drives their forced and premature obsolescence, as newer and newer APIs demand more and more powerful device defaults, meaning that the rich simply discard gadget after gadget, often in perfectly working order, because devices become simply too slow or battery intensive to run newer operating systems, web apis and more powerful applications. The poor, who can't afford to upgrade, whether that is farmers in Kenya or local authorities in England, simply miss out, and reconcile themselves to digital exclusion, security vulnerabilities, and performance restrictions.

The vast, vast majority of the electronic waste of perfectly working hardware driven by our software designs is never recycled, and a significant proportion of what is "recycled" is in fact simply dumped, in Africa, India, China. Without proper disposal mechanisms, regulatory frameworks or enforcement mechanisms, the waste full of poisonous lead, lithium, mercury and more, seeps into the soil and water and generates brain damage in the children who play and drink and occasionally work in the wasting regions.

Again, you might ask, as a technologist, business or NGO harnessing technology for positive purposes, what this has to do with you, since you've never been near a mine, have no idea how to make people recycle their devices safely, and can't control the demand for novelty and power. You are not a politician or aid worker.

And yet you can probably do more than most politicians and aid workers.

There are ways of designing our software that allow us to tap into the latest capabilities of hardware, operating systems and the web API, without killing the planet and poisoning children. In the following presentation, created for the Code For All Summit, I propose 4 principles that can help you both, enjoy your work as a technologist and build amazing apps with bells and whistles... and sleep well at night as a responsible global citizen.

1) Green By Default 2) Green Mode Design 3) Green Partnerships 4) Green Voice

The presentation below (best viewed on desktop) guides you to 3 questions each you can ask your dev team and your product team to ensure the apps you build are not built at the expense of our planet, or of people's lives. Let me know your thoughts!

In my post on the green potential of event driven architectures and AsyncApi I noted that in 2022 4.8 zettabytes of data will be transferred over IP addresses. More than all data transferred in the previous 32 years since the Internet was launched. I gave a high level overview of how to estimate the quantity of CO2 emissions generated by API data traffic, and particularly REST APIs. Using the most conservative, lowest estimate of CO2/gigabyte I could find, I arrived at a figure equivalent to driving all the cars in Shanghai for a year. Which would need the equivalent of doubling all the trees in Ireland. Every year. Plus annual, exponential increases on top of that.

So this is the Big Picture we need to keep our focus on, which can be summarised as:

1. The more data we transmit or consume, the greater our digital carbon footprint
2. The amount of data currently transmitted is a significant contributor to climate change
3. Anything we can do to reduce data transmission, in volume, frequency or duration, through greener infrastructure, architecture and back-end and front-end design patterns such as green by default; and green mode design, we should do to shift the current dismaying climate trends.

At a more granular level however the Big Picture above is your motivation and theory of change, but it's not enough to translate vision into measurable objectives.

The challenge of measurement

Use cases

You need some kind of unit of measure for benchmarking your product's current digital emissions in order to monitor and measurably improve them. This could be purely at engineering team level, incorporated into your CI pipeline to stay within a carbon budget in your ticket implementations; or it could be part of a company wide digital Lifecycle Analysis (LCA), environmental management systems (EMS), or B Corp certification process.

So how much CO2 is generated by 1GB of data? This is a case in which why you measure is more important than how you measure.

Focus on the why

Bearing in mind the Big Picture above, you benchmark in order to make measurable progress, and choose a metric in order to monitor and communicate that progress. What really matters in most cases, is not so much the precision of your unit, but the trajectory of your product and organisation.

Not to say that the precision of your measurements isn't consequential, or that expert disagreement on exact bounds or ranges mean there are no bounds or ranges you need to follow to remain rooted in evidence!

But it is to say, that for most organisational purposes, as long as you are within the ranges indicated by reputable science (meaning pick a scientifically backed metric, even if it differs from another scientifically backed metric), the precise calculus of your units of measurement is less important than how much and how fast your emissions are improving (or worsening).

Much better to have a measure that turns out to be 10% inaccurate to quantify a 50% annual improvement in emissions, and consistent progress over 5 years, than a measure with superior exactitude demonstrating 10-20% more emissions every year over the same 5 years.

Having said that, there is no exact and constant GB/kWh/CO2 correspondence, which is why there is quite a bit of scientific and policy debate in terms of arriving at precise figures.

Calculating data emissions.

Global averages

The most conservative recent figure is 0.015 kWh per GB by McGovern, and 0.0042 kg of CO2 per GB. The International Energy Agency (IAE) estimated in 2020 a 0.06 kWh/GB and 0.478 kg CO2/kWh footprint, which would result in 0.028 kg of CO2 per GB streamed.

So that shouldn't be too difficult right? Just choose one of the metrics above, and start calculating your CO2/GB benchmarks. Except, it is a bit more nuanced than that, if you're after precision.

Hardware factors

There is a difference in the emissions of the same GB of data by device type (e.g. mobile or PC), and by signal type (e.g. 3G, 4G, Wi-Fi) with emissions calculated at 0.1-0.2 kWh/GB for 4G mobile, so a lot more than the average metrics above.

It follows that if your product involves the Internet Of Things the intensity per GB will likewise vary if you're using a smart watch, a fridge, smart glasses, or an implant in your leg.

Problem is, once you've accounted for device type, not all device brands and and models within each device type are created equal, so depending on the age, brand and model your 1GB might produce completely different emissions.

Likewise which data communication protocol (e.g. HTTP, USSD, MQTT your device uses to transmit the same 1GB of data to your device will affect the emissions it emits.

Got it. So if we just apply different CO2/GB metrics per device type, per signal type and per communication protocol, then, as the Brits disconcertingly say: Bob's your uncle. Now can we go measure?

Software factors

Well, say you have 2 identical devices running on the same signal type via the same communication protocol. Different configurations, software installed, operating system, etc. will affect the electricity consumption of that identical machine upon receiving 1 GB of data.

It will be very different browsing on a minimalist Linux distribution like Porteus which is small enough to fit in an old USB stick and run entirely from system RAM, while browsing your 1GB of data using a text based browser in your terminal; than it is to browse 1GB of data on a Windows OS opening 100 Chrome tabs while having 10 desktop applications running in the background.

So let's imagine you have 2 identical machines, identically configured, in identical conditions, with identical hardware and software running. Will your elusive GB now be equivalent?

Use case factors

Well actually, no. There is also a difference in emissions according to what user behaviour that GB of data is meant to elicit.

1 GB has been estimated to be equivalent to 600 web pages, or 30 minutes of HD video (caveat emptor: previous paragraphs apply!). By now, you've read enough to be pretty sure that your identical quantity of data will produce different emissions in these two scenarios... but can you guess whether 30 mins of data and CPU intensive video or 600 super optimised web page visits is worse for the climate?

If we take an average time spent on a web page to be 52 seconds (varies hugely between industries and between websites), then 600 pages is around 8 hours on your machine viewing the screen. That is 16 times longer than a 30 minute video.

Imagine that 30 minute video was transmitted in HD, not hosted in a green cloud provider, no steps taken to optimise delivery. Meanwhile those web pages were downloaded in a single optimised request via a super optimised CDN from a green cloud provider. Clearly the emissions generated by the GB of video traffic would be incomparably higher than those of your fantastically opitimized and delivered 600 pages.

Except, all that reckless, high emission, 30 minute video traffic, would STILL use less electricity than keeping your computer monitor, CPU, background processes, etc, in use for 8 hours.

Taking everything into account so far, and inaccurately working from a global average electricity mix, streaming a GB of video will produce around 18g of CO2. In contrast, a laptop that has a life of three years will generate, including embodied carbon, 107g of CO2 per hour of use, so 828g of CO2. Nearly 50 times the 30 minute video's footprint for a single GB of data.

So now we're there, right? You just have to use the same machine to stream the same 30 minute video over the same network for your 1GB of data to translate into a single CO2 emissions metric.

Not by a long shot!

Grid intensity

The emissions of your extremely frustrating GB will vary in relation to the location and time at which you stream your 30m video, even on the same device over the same network and protocol, hosted in the same server.

Emissions fluctuate in accordance with the intensity of the electricity grid at the time you stream a video. Your GB will produce more emissions when the grid is at high intensity, and less when the grid is being powered by renewable resources, so the same GB of data will produce more or less CO2 at a different time of day. There's a variety of APIs, like Electricity Maps (global), carbonintensity.org.uk (UK) and many many more, that you can use to measure your emissions in relation to grid usage, and make your websites and applications not just carbon aware but carbon intelligent.

An example of one implementation is the fantastic https://branch.climateaction.tech website. If you look top right, you will see it has 4 performance modes, giving you most functionality at low grid usage times, and reducing the defaults at high grid intensity times. So in low grid intensity mode you get full colour images displayed by default; in moderate you get them monochrome, and in high usage mode you have to click in order to see the image. The "Live" mode automatically switches between modes depending on grid intensity.

You can see how branch magazine uses the UK grid api to measure intensity in this simple JavaScript file.

Another implementation would be Code Carbon which is more granular and calculates not just the emissions of your website or application in aggregate, but of your actual code, in relation to grid intensity. This allows you to create carbon aware queueing jobs, which basically allocate the most computing intensive jobs to the lowest grid intensity times.

Track to improve, gradually refine

So is there then one answer to the question of how many CO2 emissions are in 1 GB we can use as a consistent metric?

Alas no.

Which is to say, tools like Ecograder recommended in my earlier posts give you a nice starting point to benchmark and communicate your progress, but if you want to be thorough and maximally impactful, you need to drill down much more in both your measurements and implementations, with the tools and examples I've offered.

The most important thing, of course, is that whatever metrics and tools you choose (quick and dirty or orchestrated and precise), they help you surface your direction of travel in emissions, and empower you to reduce them month on month, year on year.

And just as you can improve your emissions year on year, you can also year on year improve the precision of your measurements, adding increasingly precise metrics, and increasingly smart automations built on those.

What you can do

As technologists, each of us can have disproportionate impact, because the technologies we work on tend to affect thousands, and sometimes millions of people. So every one of us who tweaks a product in a climate friendly way, can add up to a collective contribution that actually makes a difference.

If you're keen on being an environmentally responsible technologist, but you're not sure where to start, head over to my pinned starter toolkit post which will give you a good base to begin this journey.

If you're experienced but would like to grow your community of sustainable practice, and be exposed to new tools and design patterns, that toolkit includes leads you can follow to repos, slack groups, and resources.

The scope for action is huge. We just need to take a first step, and keep on walking.

It may at first sight seem like linking an emergent API specification to the biggest existential challenge of our time would be like asking whether a new format for restaurant menus might impact on the global obesity epidemic.

A closer look however suggests the AsyncApi specification, by accelerating and optimising event driven APIs, could help significantly reduce global emissions, in turn increasing our chances of impactful course correction. Let's break it down.

Calculating the carbon footprint of API traffic

CISCO estimates that by 2022 a gargantuan 4.8 zettabytes of data will be transferred over IP addresses. More than all data transferred in the previous 32 years since the Internet was launched.

Using the most conservative estimates, that amount of data equates to 72 million megawatt hours which in turn roughly equals 20 million tonnes of CO2. This is the equivalent of driving 4 million cars for a year. We would need to plant 620-920 million trees to offset that many emissions, which would be about 2000 Sherwood Forests or all the trees in Ireland. Every year.

These likely conservative estimates are subject to a lot of nuances, caveats and technical debate, but the conclusion is unequivocal: internet data traffic is a major source of pollution and climate change driver.

But we still haven't made the connection to AsyncApi! The next step in estimations is to roughly calculate how much of the traffic above is mediated specifically by APIs. One good proxy is Akamai, which routes 15-30% of all internet traffic. They found that 83% of all traffic through their network was API traffic, and only 27% was html website traffic. If this figure translates more broadly, which is likely, that would mean that some 16 million tonnes of CO2 are generated each year by APIs.

But what kind of APIs? In 2020 Smartbear's State Of API Report estimated 82% of APIs were REST APIs. A closer look suggests that 93-95% of APIs in their survey are essentially synchronous command response APIs, and only 5-7% are asynchronous, event driven APIs. Again, the precise numbers will differ, but the overall distribution is clear. A very significant proportion of those APIs are queried or query via polling, where repeated calls are made to see if there has been a state change. According to a 2013 estimate by Zapier, 98.5% of polling requests return empty, meaning all the emissions involved across the request lifecycle are entirely wasted. The situation has almost certainly improved dramatically in the intervening 9 years, but is an example of the type of inefficiencies involved.

Which gets us closer to AsyncApi!

The green potential of event driven architecthure

Increasingly, there is a shift from command driven, to event driven architectures, where instead of waiting for a specific command to trigger a behaviour, that behaviour is tied and automated asynchronously to changes in conditions, that is to say, events. This has huge potential and possibilities, which is why it is growing so rapidly as an architectural paradigm. Gartner projected that by the end of this year (2022)

• Event notifications will form part of over 60% of new digital business solutions.
• Over 50% of business organizations will participate in event-driven digital business ecosystems.
• 50% of organizations managing APIs will incorporate mediation of event notifications into their operations.
• Most leading providers of application platforms will include high-productivity tools for event-driven design.

The environmental potential of switching from traditional REST APIs and similar command-request approaches, is that you can tie behaviour and consumption to climate aware triggers. You could apply graceful degradation when the grid is not running on renewables, and full performance when it is. You could have an IoT device automatically switch to low energy mode when it doesn't require constant activation. Instead of relying on people to remember to turn off lights or devices, they could be switched on and off upon detecting the user's presence or absence. Indeed, such architectures underpin most smart devices.

The role of AsyncApi in greening event-driven communication

One of the greatest barriers to adoption of this paradigm, which could significantly cut into the amount of data transferred and energy consumed by the internet, is the historic absence of a common language to facilitate interoperability. This is where AsyncAPI (finally!) comes in. It provides a standard and a language to describe event based, asynchronous communication, greatly enabling not just inter-api communication, but also drastically cutting developer design and implementation time, by making possible a wide range of automations, akin to the more familiar OpenApi. Such a common language acts as a universal translator, which allows the emergence of a network of devices, workflows and tools attuned to one another in an emergent, inductive way.

In addition, the AsyncApi community has the historic opportunity, at this early stage in the spec's evolution, to dedicate serious attention to any way in which it could not just describe, but nudge the nature of event driven communication that is coming, or like Gibson said, is here, just not evenly distributed. It may be that there are elements that could be added to the specification that could greatly increase the environmental potential of all applications built in line with its specification. For instance, being able to flag whether a network is delay tolerant or not, could make a huge difference toward allowing a wide range of energy aware applications, as well as widening digital access and inclusion, and facilitating innovation, specially in the Global South.

This is a very early, yet therefore also a key moment. Event driven, asynchronous communication is, with cloud and serverless, part of the next (current?) wave of technological paradigms. If AsyncApi can enable and influence the transition from a command-request, synchronous, and climate blind ecosystem, to an event-driven, asynchronous, and environmentally conscious paradigm, then, after all this, yes, I do believe it could be part of making an observable dent on world emissions, and therefore on climate change.

For a higher level introduction to the shift to an event driven society, and AsyncApi, you can dive into my talk on the subject for ApiDays in my talks section.

Green Mode Design vs Green By Default

Before that I want to emphasise again that Green Mode Design, integrating both, "graceful degradation" and "user control and freedom", is not a replacement for green by default design. We should absolutely try and ensure that our products are as climate friendly as possible, before a user ever engages with our app. This is a space where not only developers but specially browsers and standards have a key role to play.

But even the greenest commercial website or app cannot impose a maximalist approach to CO2 optimisation and expect to survive.

What would Netflix or Youtube be without videos? Or with minimal viable quality videos only? What would a newspaper site be without images? What would a design agency website be if it was pure black and white? What would most web apps be without any JavaScript?

This is where Green Mode Design complements Green By Default design. The realistic default that meets not just the environmental, but also the economic and social pillars of sustainability, will still be more energy intensive than will be necessary at all times for all users.

If I go to youtube to listen, without watching, to a music video playlist - do I need to keep streaming the videos? Being able to toggle video streams and sound only would be not just good for the environment, but for my CPU and battery and general speed of my device, so not only "altruistic" consumers, but "selfish" consumers would want to toggle such a feature.

And where self-interest and altruism coincide, behaviour change is much easier to scale.

Additionally, given the realistic lag between advocating for Green By Default, and making it standard, Green Mode Design empowers users to override high emission websites to practice client side digital sobriety.

This means that emission reductions do not have to wait for sufficient negative consensus among all the stakeholders, but can start with consumers, which in turn will accelerate commercial and normative adoption.

Just one powerful green mode browser extension gaining traction across major browsers could potentially have a significant impact on both, emissions, and consumer awareness and behaviour.

What would Green Mode implementation actually look like?

There are many vectors out there that could be part of green mode design, but I think they could be integrated into 4 customisable modes and intensities of green mode design:

1 climate aware

Client side optimisation without degradation (e.g. unused tab suspension, climate aware metrics/monitoring, ad/tracker blocking/service worker enabled intelligent caching).

2 climate friendly

Graceful degradation of performance (e.g. all the above + more aggressive service worker caching; blocked image or videos by default, clicking on an image link displays it in a customisable default low-fi quality; clicking on a video link defaults to podcast mode (sound only), or even reader mode (transcript only).

3 climate first

Maximum graceful degradation without loss of core functionality ( "print mode", no javascript, minimal css, maximum backward device compatibility, accessibility options (e.g. only text to speech including alt for images, and no other visuals; change font colour or size, etc - this + backward compatibility increases climate resilience)

4 smart mode

Customisable default triggers for switching between 1-3 (High CPU, high daily CO2 consumption, full screen mode (degrade all other tabs), non-green cloud host detected, high CO2 website, time of day (this could link to focus mode design thinking).

What can be done already?

1) Consumers

Can achieve most of the above client side via browser extensions, but obviously it will be less seamless with more overhead than at the developer level, particularly in the absence of a Green Mode app that integrates all 4 levels in a comprehensive way.

2 Developers

Have all the tools to implement optional graceful degradation, like client caching both high performance and low fi versions of sites in the client (a bit like the prerendering used already in SPAs to serve crawlers and users different versions). You could also design every app and specially page for graceful degradation to work with low or no js. A lot of accessibility design would also be pertinent. And give your users high, mid and low performance options, plus smart mode, on your UI.

The only example I have come across (do you know any more?) of implementing all 4 modes I propose here is the fantastic branch magazine site. There is more graceful degradation options that could be added to each of Branch magazine's 4 modes in terms of user control and freedom, but this is a fantastic illustration of the design concept I'm proposing.

What cannot be done yet?

3 Browsers

Could but are yet to implement much more comprehensive green mode features than Edge's energy efficient mode, which itself is yet to be replicated by competitors.

• If we could enable service worker type caching on the client side, with the same core strategies available, that could potentially have large impacts on data consumption and computer usage. If you could for instance toggle a feature that implements stale while revalidate strategies if no similar service workers are active from the site itself, you could drastically reduce web traffic and consumption.

• if you could download rather than stream by default, with streaming mode operating only as a buffer until the full download completes, that could also make a difference, specially if you could "expire" the downloads after x time, removing the downloads by default, and giving the user power to keep the ones they like.

• if you could integrate CO2 counters into the browser itself, or at least to dev tools and lighthouse and equivalents, that could also become a powerful behavioural nudge. There are doubtless many, many more ways in which browsers could enable the proposed 4 layers of Green Mode design. Please share any suggestions or ideas.

4 Standards and specifications

The other potentially game changing element that is yet to land, would be specifications and standards to integrate both, green by default, and green mode by default.

• Sites that conform to green and green mode standards could be prioritised by search engines and similar incentives, as is the case with Accessibility.

• Green mode design support (user controlled graceful degradation layers) could perhaps also be incorporated into OpenApi and AsyncApi specifications. This would align with trends in delay tolerant networks, set to proliferate in the coming decade driven by commercial, environmental and humanitarian interests.

• Green certifications could be mainstreamed and integrated into things like Amazon's Green Pledge certification and other impact multipliers.

Where to next?

At the moment the 4 key constituents (consumers, devs, browsers and standards) are at different places in this design trajectory.

Consumers

I suspect consumers are proportionally and numerically the furthest in commitment, but lack the means to express it technologically in the web space.

Green marketing and even green washing are successful because consumer demand is real. So a browser extension could be the most rapidly scalable win, with the most downstream impacts.

If there is evidence of demand, it follows that software conventions and web and browser standards will change more rapidly. If we could reach a tipping point, we could radically improve our industry's environmental impact on emissions, waste and raw materials, with many secondary benefits.

The biggest limitation in this area is the fact that browser extensions do not work on mobile.

Developers

Assuming the statistics on people's readiness to make changes to protect the climate, I estimate that there are c.9 million developers waiting for the right messaging, tooling and behavioural nudging to implement greener software and design practices, particularly among younger ones.

This means that those of us who have been advancing the practice of climate friendly design and programming, including ideas such as Green Mode Design, need to step out of the "green" community and bring the messaging, tutorials, libraries and resources to non environmental communities.

Gaining support for incentivising green software in key platforms, from the big cloud providers, to ecosystems like android and apple stores, NPM, Steam or Github.

Above all, it means systematic efforts to incorporate green approaches and perspectives, including Green Mode design, into the junior developer pipelines at scale. Computer Science and adjacent university curricula, bootcamp curricula, popular webdev trainers on YouTube, Udemy, etc, and professional development gateways like Pluralsight, or accreditation bodies like ISAQB.

Browsers

The most impactful space for Green Mode design is probably at the browser level. Given the acceleration of sustainable consumption patterns and priorities this could be a source of competitive advantage and traction.

With 60% of mobile wallets being in Africa, Green Mode options, compatible with less powerful mobile devices, delay tolerant networks and less intensive data plans, Green Mode functionalities at the mobile browser level could hugely expand commercial reach and digital inclusion in the Global South.

For browsers associated with a hardware ecosystem, the opportunities to extend battery life, reduce energy consumption and increase usability are particularly strong.

Extending at least green extensions/plugins functionality to the mobile browser sphere could also greatly enable innovation and change user behaviour.

I believe sustainability discussions are ongoing in many browser companies. These need to deepen, widen and be more publicly visible, and bodies like the Green Software Foundation and the UN ITU could play a role in thus.

Standards and Specifications

Work is currently underway to establish a Sustainable Design Working Group able to make recommendations to WC3. The United Nations Envoy for Technology is also currently consulting on a new Global Digital Compact to shape national regulatory approaches. The UN Secretary General's projected Forum of the Future has digital components across most priority agendas and the Internet Governance Forum brings together governments and civil society stakeholders.

The green web/green software community needs to be present and proactive in these processes which have the potential to influence international government policies for a long time to come. Tracking the standards and regulatory environment around green web indicators would be an important first step, and the Green Web Foundation is probably well placed to lead on this, perhaps through its Fellowship programme.

Finally, the Green Software community needs to engage with emerging specifications and protocols, like OpenApi, AsyncApi or MQQT.

These are of course broader strategies than Green Mode Design, but Green Mode Design could be one impactful low hanging fruit that could be part of the above strategy and vision.

I would love to hear from colleagues if they resonate with these proposals, and what alternatives or refinements might be needed. Together I truly believe we can shift the environmental direction of the Internet.

Defining technical debt

Very often, tech debt is defined as a conscious trade off of quality for speed, or a result of poor design decisions. But while both of those are good examples of tech debt, tech debt can also come to absolutely top quality code: if it fails to evolve with the tech ecosystem. The cutting edge app of 2010 is very often the creaky, slow and plainful monolith of in 2020. It's not that the original choices were suboptimal: it's that time moves fast in tech, and code needs to constantly evolve to keep in sync.

But not all technical debt is created equal.

Below is a model you may find useful in mapping different parts of your application.

Technical Debt Accounting Model

Low Interest Technical Debt

Technical debt, like financial debt, can be useful, helping you enter the market and gain traction with an MVP, or allowing you to innovate, or rebuild. That's when your debt is "low interest", you understand the trade offs and the pain is in your future, with a plan to pay it back before it gets painful.

High Interest Technical Debt

High interest debt, that's risky, and much harder to pay off. Here your technical pain is not ahead but right now, and if you're nor careful, it will compound into a debt default. Technical debt now places serious operational and commercial constraints on the entire company, and creates reputational risks, from security breaches to service interruption.

Technical Debt Default

This is where your company is at existential risk because of technical debt. Your core platforms may have passed End Of Life with widely publicised critical exploits, and you advertise this in your website headers. Your system has become so bloated and is so highly coupled that no one really knows what everything does, and everyone is afraid to change things because every change creates side-effects. Your new features grind to a halt, your devs leave, your company stagnates and loses users to more reliable competitors.

Technical Debt Accounting

So equipped with this model for understanding and categorising your technical debt, the questions of implementation remain:

• How do you rigorously measure it to know in which category any given part of your codebase falls?

• How do you know which specific classes are most tightly coupled or more likely to create side effects or most difficult to understand?

• How do you measure the impact, as opposed to the presence of technical debt on your team or company's feature development process?

• How do you estimate its financial cost?

• How do you choose which areas of the code to refactor first?

• How do you know when replacement is the only option?

• How do you persuade the business of the need to invest in technical debt?

Technical debt metrics

Metrics for measuring technical debt which I cover in my training course include formulas for code complexity, cognitive complexity, class and method complexity, afferent and efferent coupling (one is likely to have side effects in many parts of the code, the other is likely to be vulnerable to changes in many parts of the code); package dependency metrics and more. There are also powerful visualisations which can help you find the seams in your application, identifying the low hanging fruit for modularising or service decoupling, as well as the highest risk areas. The metrics above have also proven to be 70-80% predictive of bugs, so they allow you to identify likely bug prone classes and methods.

A different type of metric is escape velocity, the amount of times new work releases bugs into production. There are algorithms like szz that estimate this in repository commit histories, both globally and by file.

A different approach uses issue trackers like Jira. You can create queries and even dashboards that quantify and monitor live the rate at which tickets previously marked as done are reopened. You can also track the number and rate of tickets marked as "bug" or "fix", the time it takes to respond to a bug, and to resolve it. These process based metrics are particularly important because they help you quantify and cost the compounding of technical debt into operational and strategic debt. You can track how much time is spent on bugs and fixes, and this is time deducted from new features, with associated opportunity and competitiveness costs, and also user pain points, which can affect adoption and retention.

These process metrics allow you to put financial estimates to your technical debt. You can track how many hours your product team (inc. devs, managers, product owners, qa, customer service) spend on bugs, and get pretty precise figures of pro-rata aggregated staff costs. If you compare this to revenue, profit and turnover streams, you can see how significant a cost that is beyond the raw amount, as it might negate the entire profit from a product vertical. You can also, more roughly, estimate the cost and frequency of roadmap delays or slowdowns, against commercial projections predicated on them as a proxy for opportunity costs. Finally you can make correlations between customer acquisition and retention and bug introduction rates as well as customer complaints. This kind of analysis is essential to get business buy-in for investing in technical debt, and for identifying where in my proposed framework your product might be.

Why technical debt is never only technical

Technical debt also compounds in to security debt, as it almost always entails vulnerabilities that can be tracked and measured via static analysis tools like Sonar, or API testing tools. Finally, technical debt compounds into environmental debt, as you can link speed, requests, data transmission, server intensity, infrastructure configuration and more to higher CO2 emissions, battery and CPU usage, and several downstream and upstream costs. This could have implications to your ESG accounting, your brand values, and your transition to Net Zero.

You can find an illustration of the above framework, metrics and tooling in a talk I recently gave on the subject. Indeed, you may have noticed I added a new Tech Talks section. OK, no way you noticed. It has recordings from meetups, conferences and even COP26 on a wide range of software engineering subjects.

How to get training in Technical Debt Management and Accounting

Also known as shameless plug.

I am genuinely thrilled to have been selected to give a 1 day online workshop on the subject in November by the International Standard in Training and Certification of Software Architects - probably the world's foremost software architecture certification body.

To be dedicated 9 hours (there's also a follow-on talk on Modernising Monoliths) at one of the world's leading architecture conferences, at the invitation of such a literal standard setter, feels humbling, exciting and challenging, all at the same time. The talk above can be taken as a taster for my online workshop, which will actually train you to apply this framework, tools and metrics in practice.

If you enjoy it, you might want to sign up for the (online) workshop.

Do please share any feedback on this blog post or the talk above, and suggestions for things I should clarify or add ahead of the course.

Also check out the entire conference and training days, there are some really fantastic talks in the programme!

What is Green Mode design?

What I'm choosing to call Green Mode design is the combination of two UX principles:

• user control and freedom: allowing users to control their experience of the system while providing means to undo their selections.

• graceful degradation: the ability of a system to degrade its performance without affecting its core functionality.

So Green Mode design could be defined as:

giving users a reversible option for degraded but still functional performance in exchange for reduced emissions and longer device life.

It surprises me that I have so far only found a single website (do you know of any others?) with a green mode toggle: https://theorganicagency.com/our-website-green-mode.

I would have thought there would be hundreds if not thousands of examples, given we learned the art of "graceful degradation" well over a decade ago, and so many of us deeply care about climate change.

The rise and fall of graceful degradation

Graceful degradation, in web development, generally means that you build your site to take advantage of all the features of the web APIs supported by the latest browsers, but also create fallbacks for people using older browsers or devices.

Interest in graceful degradation peaked around 2011, because the difference in CSS and Javascript support between browsers was massive, particularly with Internet Explorer 8, which had the least functionality and the largest market share.

This meant that every website had to cater to both, the shiny new kid on the block who excelled at gymnastics (Chrome would edge out Internet Explorer by 2012), and the less than athletic grandparent who controlled the PCs.

To grow and retain your website's user base, therefore, it became common practice to create a high performance version with a low performance fallback for laggards.

To experience a good example of graceful degradation, if you have access to gmail, go to your inbox on the browser, and once there, disable javascript. You will get an option to view your mailbox in html only. Accept and behold graceful degradation in action.

Before:

After:

As the web api became more standardised, and browsers more interchangeable, graceful degradation largely faded from developer discourse, as an artefact of an earlier, more painful era.

You could now safely let rip and flex your web muscles. Which of course also meant that we were pretty much responsible for exponentially increasing planetary emissions, with more and more powerful applications requiring more and more energy and imposing faster and faster hardware obsolescence and waste.

Implementing Green Mode Design

Many of us are familiar with the eco mode option in cars. When enabled, the system modulates things like air conditioning, heated seats or other functions to take away pressure from the engine.

The benefit is better fuel efficiency, lower emissions and cheaper costs. The trade off is that it inhibits the performance of the engine (acceleration, gear shifts), and degrades things like lights (less bright) and air conditioning (more interruptions, less power).

While eco mode is ideal for most trips, it's not suited for driving up steep hills, or accelerating quickly to overtake. Choosing maximum performance would make more sense in these situations, both for safety and for the car's health and longevity.

Similarly, you might not choose graceful degradation on a website for high end gaming, watching a blockbuster, or sleuthing through image based OSINT.

But for day to day use, you probably don't need all the animations, background videos, images and trackers when reading articles, listening to music on YouTube in the background or aimlessly procrastinating.

Will the real slim browsers please stand up?

If the option for excluding such "extras" when requesting web pages was a standard feature available to the 5 billion people that use browsers, the impact of even fractional adoption would reduce global emissions in a noticeable way.

And yet, compared to consumer electronics, the web ecosystem has been slow on the uptake, to put it politely. Green Mode Design (in practice if not in name) is fast becoming standard in consumer devices, with eco mode an option from wearables to laptops, mobile phones to whole smart houses.

It was only in the last year that Microsoft released a still little known feature, efficiency mode.

It aggressively reduces CPU and RAM usage by lowering video and animation quality and putting to sleep unused tabs. This is a pretty weak offering, considering that the tab suspender extension is much more powerful and fine grained.

I have not come across any efficiency mode equivalents in Chrome, Safari or Firefox. Some of the features are replicated, like tab sleeping and more esoteric optimisations like wake up javascript throttling, but they are not designed as user controlled options, so they do not conform to my definition of Green Mode Design, offering graceful degradation but no meaningful user control and freedom.

It is a bit bizarre then for the web to be so far behind this curve, when there is so, so much that could be done by browsers to offer truly customisable green mode options, with potentially huge impact on climate change.

Does that mean that green mode is largely impossible for responsible consumers?

Hacking Green Mode on the user side

While there is no native, comprehensive tool to achieve meaningful and customisable green mode in browsing the web, there are ways to "hack" a green mode approximation for responsible net surfers thanks to the efforts of enterprising devs in the browser extension ecosystem. I have already name checked Tab Suspender:

As you can see you can create powerful rules. As a pathological multi-tabber (if multi-tabbing was a sport, I'd have a shot at the Olympics), this has been a godsend. After my chosen interval, the tab goes completely inactive, while its ghost remains ready to come alive on my return:

My CPU and ram usage has, since I added the extension, been very dramatically reduced.

Other extensions allow you to block (not hide) adverts from youtube videos; block (not hide) videos from youtube, only streaming the sound, which is great if you use youtube for music or podcasts.

Yet more extensions allow you to disable JavaScript with a quick toggle on a single page (as opposed to the browser as a whole in the settings).

There are extensions to automatically choose the minimum resolution of videos you stream (the greatest source of web emissions on the user side).

You can also use extensions to monitor your web consumption and emissions, and there are also extensions that plant trees every time you open a new tab, or search the net, or shop online.

I hope to devote a separate blog post to this extension ecosystem.

It has inspired me to set myself the goal, this year, to create an open source "green mode" extension, that integrates all of these features and more in a granular way.

Reclaiming Graceful Degradation for Green Mode web design

Instead of designing fallbacks for antiquated browsers, like we used to as standard practice, web developers could design fallbacks for user facing "green mode" toggles, which should be present in every web application we're responsible for.

Ideally we would offer more than on/off options. You could have green/greener/greenest options, with increasing levels of degradation that do not break core functionality.

That way you could go from this: https://moves.basicagency.com/

To this (beware, heavy swearing ahead): https://tinyurl.com/sweary-but-ecofriendly

With less extreme options in between.

Call to action

Consider this post an invitation to all web developers to reach into our drawer and dust off the graceful degradation manual, and reclaim it as a tool for climate action.

Just as developer design choices have been instrumental in our industry outstripping aviation as polluter, developer design choices can be instrumental in making our industry a lever of sustainability.

And when you read more about the connection between web development and climate change, it's easy to feel not just fatalistic, but guilty, seeing as the code you continuously deploy into the wild, the apps you lovingly (or frustratingly) maintain, the servers you consume, when added to the work of all your peers, account for as many CO2 emissions as the whole of aviation industry!

Everyone tells you to cut down on flying, but who tells you to cut down on <video> tags?

Still, we're not fatalists, we're software engineers: problem solving is what we do. Every week we get to feel like crime scene investigators, obviously doomed idiots, and certified geniuses, twice over. In a single day.

Being responsible for so many emissions, counter-intuitively also gives us an extraordinary opportunity for postive inpact.

Given the scale of much of what we work on, if just a small percent of us commit to a green web, our impact on emissions could be exponential.

Still, if you're like me, you may be willing, but not know how to start. Green web patterns are not yet regularly discussed in the spaces where devs can be spotted in the wild.

So here are some resources that might help get you started.

The green web journey began for me when I stumbled across this fantastic blog post by Phil Sturgeon of Build APis You Don't Hate fame.

This led me to the awesome earth collection, a catalogue of all the tools and ideas you might want to start with.

Soon after, I was invited to organise a panel and present at COP26+ on Engineering and Climate Change: Remaking the Future at the invitation of the International Environment Forum.

The experience made me aware of the power of engineering communities to both inform, and motivate, and I set about looking for the best one in the tech space.

I am confident I found it in ClimateAction.tech. They have built a fantastic and impactful green tech community, including many of the pioneers and leading voices in the green software movement.

From their website you can join the Slack group which is probably the best single place to keep track of developments, network with fellow travellers and ask questions.

Other good resources to get started are:

The Green Software Foundation and its podcast, Environment Variables

Gaël Duez' podcast Green I/O

The Well Architected Framework's Sustainability Pillar

https://www.cloudcarbonfootprint.org

As to the skillset involved in environmentally aware software, I suspect you'll find you already have a strong foundation.

It just so happens that what's required for green tech is exactly what's required to reduce costs, cpu usage, improve speed and user experience in any web application! These should be part of the arsenal of any experienced engineer, and part of the journey of every committed junior one.

• Move your application to a (greener) cloud provider/zone
• Make your content delivery as local to the client as possible (e.g. via CDNs)
• Minimise your page loads and data consumption by targeted caching strategies using service workers
• Design your APIs to minimise http requests and data exchanges
• Optimise your images and reduce the javascript and in general the data you send to the client front end, by minification and exclusion.

You may not have thought about the emissions side too much to date, but I suspect you already know a thing or two about performance optimisation, api design, caching, and graceful degradation.

Which means you're set to go on your green journey, equipped with a community, good resources, and your own accumulated, growing skill.