Tackling climate change as a developer

Did you know that the internet produces more than 2.5% of global emissions or one billion tonnes of greenhouse gases a year ?

This amount is currently more than the aviation industry and is expected to triple in the next 10 years. The communication industry is estimated to be responsible for 14-20% of emissions by 2040.

As developers, we wanted to establish if there was anything we could do to help reduce this, besides switching our computers to be powered by renewable energy.

Well yes actually.

The code you write now will likely still be in use in 5-10 years’ time. The servers your code is running on are running 24 hours a day, 7 days a week. Your thousands of end users are using power to consume your content. The choices you make could make hundreds of times the difference of switching your development machine to run on renewables.

You can make a huge difference in the CO₂ produced by your site or application with the code you write now and the decisions you make in your development.

Let’s take a look at some of those choices by considering the following areas:

• Front end choices
• Back end choices
• Hosting choices
• Network choices

Front end choices

The code you write could be loaded thousands of times, on millions of devices. Downloading that content takes power. Running the code takes power.

Here are some ideas that could help reduce power use in data transfer and on the end users’ machines.

• Dark mode saves up to 30% power on OLED screens. These types of screens are used increasingly on mobile devices and high end desktop screens.
• Rather than polling for a status or data, use a pub/sub pattern.
• Reduce data sent on very frequent calls. Only send or request what is necessary.
• If using Canvas animations there are some good improvements to be made, for example pre-render off-screen.
• Remember bitwise operations on integers is more efficient than calcs on floating point values.
• Cache in the browser using Cache js api or JS session storage.
• Remove old unused js code and modules to save data transfer costs.
• Load only the parts of libraries you need (eg. build a custom loadash or bootstrap version, using only the modules you need) 
• Ensure no memory leaks in the browser by checking the Performance tab in Chrome.

Back end choices

The code you write can almost always be optimized. This not only saves power usage, but hosting costs as well. Some small changes can have orders of magnitude changes in performance.

Here are some considerations to improving your back end code.

• Caching. Lazy create objects. Reduce hitting the database.
• Multi- threading is more efficient than using a single thread.
• GraphQL to give api consumers the option to only receive what they need.
• Always use algorithms with the least computational complexity.
• Rewrite algorithms to get same results with fewer calculations.
• Use bitwize operations where possible, the calculations use fewer cpu cycles.
• Use tools to run performance tests.

Hosting choices

The servers you decide to host your application on has perhaps the biggest impact on your CO₂ footprint. After all, high end servers can draw up to 800w of power, and run 24 hours a day, 365 days a year.

With database server and backup servers, this can add up to tonnes of CO₂ produced, depending on where you source your server power from.

Here are some ideas to reduce your footprint.

• Choose green power for your own machine
• Choose green power for hosting
• Host in a Data Centre rather than On Premise. This could save up to 93% of power used compared to self-hosting . If you do switch, Microsoft and Google offer the best CO₂ reduction guarantees. Amazon AWS is improving but lags the others.
  
  • Microsoft has been carbon neutral since 2012
  • AWS is 50% renewable for 2018, pledged to be 80% by 2024
  • Google Cloud is 100% renewable power
• If you do have On Premise hosting, shut down unused machines. One estimate had up to 30% of running computers were not being used in organizations.

Network choices

It is often ignored but sending data over the internet takes power. Between your server and the client, data may pass through tens of routers and signal boosters, often travelling under oceans and across continents. By reducing the distance and amount of data that needs to travel, you reduce your overall footprint.

Here are some suggestions.

• Minimize data movement within your network. Have the code processing the data be close to the data.
• Again, reduce the data sent over the network to only what is needed.
• Use a CDN to keep data close to your customers. But use the right CDN.
  • Akamai has pledged to be 50% renewable by 2020
  • Cloudflare purchases RECs to match 100%

Measuring data output

As the developer is making changes and improvements on a web project, it is all too easy to mess things up. There are ways of catching these mistakes: unit tests, code review, code analysis, end-to-end tests and more. However, we have not had a reliable, automated way of catching issues that cause bundle size and transferred bytes to shoot up.

As it happens, there is a solid way of measuring data transferred over the network when visiting a site. Fire up Chrome, hit F12 and take notice of the numbers on the network tab. A tad manual and time consuming to be of much use, but something we can work with. The data and more is however available via JavaScript Performance API. The support is not the best across the browsers, but for measuring and testing, it’s enough.

On a recent project, we’ve included series of Selenium tests calling the performance API, collecting the same resource load data available in the Chrome developer tools. From the tests the data is pushed to a storage account, from where we can get a point of reference for future builds and tests.

This is currently where we are at. The intended use for the data is to raise a warning and/or an error if the route load size increases too much on a subsequent build. Testing caching this way should also be possible. There is also no reason not to gather the data for all test cases: filling forms, navigating wizards and such. Shooting stray XHRs in a SPA is even easier than messing the bundling up.

Once included into a CI/CD pipeline, we’ve added another guard against developer error. In the future, we should be seeing red or yellow when things have been going left in performance and environmental sense

Conclusions

It has been fairly difficult in researching this post to determine how much CO₂ you could save, as it is so dependent on how busy your site is, where it is hosted, where your customers are located, what devices they use and what they actually do on your site. However, this post could be summed up in a few bullet points for you to consider as a developer.

• Host with a company using 100% renewable energy
• Reduce server loads
• Reduce data sent to the client
• Reduce the distance that data is sent

These are some of the ideas we have come up with to reduce our CO₂ footprint now and in the future. Read more about Innofactor's sustainability.

Simon Barrow

Simon Barrow is a Senior Full Stack Developer at Innofactor with 18 years of commercial experience building ASP.NET based sites and applications in Australia, the UK and Finland. He likes to get outdoors, and is a big believer in protecting the planet and nature for future generations.

Janne Forsell

Janne is a Tech Lead at Innofactor. In addition, he is a games developer on his 3rd year into .NET / VueJS adventure.