"Without data, you’re just another person with an opinion." - W. Edwards Deming

In this post, I will share a general overview of what you can measure — and give a general direction on how you may improve things. No deep dives yet, just some introductions.

But first, let's cover the GHG protocol. The Greenhouse Gas protocol provides standards, guidance, tools, and training for business and government to measure and manage climate-warming emissions. It describes three main categories.

Scope 1 are direct emissions from operations owned or controlled by the reporting organization, such as on-site fuel combustion or fleet vehicles.

Scope 2 are indirect emissions related to emission generation of purchased energy, such as heat and electricity.

Scope 3 emissions are everything else that the organization cannot control, such as transportation, extraction of raw materials, product use, disposal, and third-party services. The device you're reading this article on also falls into this category.

The entire stack of your application (frontend, backend, servers) falls under scope 3, although there are some exceptions when dealing with servers.

There are many things that can be measured, but I will focus on these three aspects: Frontend, Backend and Servers.

Frontend

It is pretty easy to get some pretty detailed results on performance, accessibility, SEO, PWA, and even best practices on your site with a synthetic monitoring tool such as Lighthouse.

However, measuring web sustainability, is a bit harder.

Of course, your site is likely to be pretty sustainable if you have a great Lighthouse score. If your site performances well, then your website is probably not too big in bytes (on initial load!). And if your site scores high on accessibility, it is likely your site has simpler or faster flows — which could mean you're already transferring fewer bytes and putting a smaller strain on the client's device.

But how can we measure the sustainability part, in addition to the already essential metrics on your site?

Bytes over the network

All bytes sent over the network from the data center to your client's devices to serve your webpage and its assets produce carbon emissions.

There is a way to estimate the number of carbon emissions produced by using CO2.js, assuming you have the data. This already gives a great insight. You can also submit your site on Website Carbon and get an approximated result based on the number of visitors you have. Then again, this is on the initial load, and does not consider further user interactions.

There are many ways to reduce bytes over the network, like using optimized images, lazy-loading and removing dead (unused) code.

Power usage on client devices

If your site uses animations, lots of media or has unoptimized code, your client's device requires more processing power and therefore drains the battery faster. Which in turn requires the user to charge the device and draw power from the grid. You can reduce power usage on devices by using several techniques, one of which is Progressive Enhancement — a topic we will dive into in a later post.

Gathering power usage on all client devices is just about impossible, but as a developer, you can inspect the energy usage of your site on your device using Firefox's built-in Power profiler.

Support on older devices

The production of your device costs more than its usage, so supporting older devices is critical if you want your visitors to use your app on their older devices. When dealing with web applications, we can't detect which hardware device is being used, but we can make sure your site performs well.

Backend

Reduce networking

Again, all bytes over the network produce carbon, even when you're fetching data from an external API or from a database. Try to keep your servers (whether with IaaS, PaaS, SaaS or which ever abbreviation 😅) as close to each other as possible to reduce bytes over the network — all routers and switches play their part too!

You can also apply caching strategies to reduce data fetching and keep data in memory for a certain amount of time. But beware: “caching is hard, invalidating is harder”!

Monitoring

There are many ways to monitor your backend applications, its CPU, memory usage, network usage among other things. This way, you might be able to track where performance of your app could be improved. One of these tools is New Relic, but it's not just limited to backend applications, it's for your entire stack.

Servers

Auto-scaling

Make use of auto-scaling if your applications are stateless. Start with just one server and scale up when the load goes up.

Downsizing machines

Some of your machines might be over-provisioned. Monitoring your applications in your Cloud provider's dashboard or using New Relic should give you a good insight.

If you combine this with auto-scaling, you don't need a big server (premature vertical scaling) at all times, but add more servers as the load increases (horizontal scaling). This also reduces costs.

Serverless

Serverless, of course, isn't actually serverless, but it is a great way to not provision and manage your own servers, and make use of the already running servers in the data center of your Cloud provider. Serverless functions scale automatically (once they're warmed-up) and there is plenty of support for several languages. It does require rewriting your application if you already have something in place.

Green hosting

Making sure your hosting provider is using green energy is a great way — maybe even the best — to reduce carbon. There are even companies (like Leafcloud) that re-use heat from their data centers to warm apartments or swimming pools.

Reporting tools

Azure, Google Cloud, and AWS all provide reporting tools for carbon emissions. Although, they're not really transparent about their own calculations, it should give you some insight.

Zombie workloads

Most applications that have been running for a while have zombie workloads. Processes that are still running, and everyone is afraid to touch it because the only ones who knew what it is for already left the company.

Turn off machines

Furthermore, you can turn off your test or staging machines on non-working hours. This also reduces costs!

Round-up

So, this should have given you a few pointers on where you can investigate carbon emissions on your own application across your entire stack.

As always, if you have any feedback, tips, or comments — don't hesitate to leave them in the section below!