Web Development and the Environment

I used to work for a company called 2degrees Network, whose digital platform helped organisations work towards their sustainability targets. Its name refers to the risks of a 2°C rise in global average temperature. That is not a single point beyond which everything is lost: the IPCC's 2018 assessment explains that many risks are lower at 1.5°C than at 2°C. The amount of warming we avoid still matters.

The Climate Crisis is a big issue. It touches every part of our lives and isn't going away any time soon. However, there are things that we can do as a group to slow it down and change our course, and (even though most of those things aren't even on the scale of what we could achieve if big corporations or governments changed their ways), if everyone pitches in we might be able to avoid the worst‑case scenarios.

Websites depend on physical devices, networks and data centres, so our work has an environmental cost. Web development is one part of that much wider digital footprint; figures for the whole sector should not be attributed to websites alone.

The Problem

There's no reason to beat around the bush: The Shift Project's March 2019 report estimated that digital technology accounted for 3.7% of global greenhouse‑gas emissions in 2018. Its scope includes producing and using devices, networks and servers, rather than just running websites.

The report also projects that this share could roughly double by 2025 if data traffic continues growing by 30% a year. That is a scenario based on assumptions about growth and efficiency, not an inevitable outcome.

One of the biggest issues facing us with the way that the internet pollutes is that there are so many facets to it. The production, delivery, and powering of devices people use to access the internet is a big deal, but so too is the energy used to power the data centres that hold servers, which host the websites those people are visiting. Then, there are the emissions involved in building and maintaining infrastructure that delivers the internet to public buildings and into people's homes.

For the purposes of this article, let's keep it (as much as I can) focused on web development. We'll be looking specifically at the way that websites affect the environment; how hosting, bandwidth usage, and the way users interact with websites have changed over time, where they are headed in the future, what the issues are, and how you and I just might be able to make a difference.

Heavyweight Webpages

During the 2010s, websites became more complex, interactive and bulky. Page‑weight data shows that growth in downloaded bytes, although it does not directly measure the resulting emissions.

The HTTP Archive page‑weight timeline below is a snapshot ending on 1 April 2021. It shows a substantial rise in transferred kilobytes for desktop and mobile pages over the period shown. The mobile series starts later than the desktop series, so their starting points need care when making comparisons.

It is useful to look at request counts alongside transferred bytes. A page can make fewer requests yet download more data if the individual resources become larger. The chart above shows total kilobytes, not image or video request counts.

So what is going on here? Why has the average size of a webpage gone through the roof?

Resource Size is on the Rise

Unsurprisingly images and videos are a large contributing factor to driving the weight of web pages up. Average image sizes have increased, and video sizes are up too. We're using bigger, higher‑quality, and (in the case of videos) longer media.

This all makes perfect sense: device screens are bigger and higher‑resolution so developers are taking advantage of the fact that internet speeds are also faster, to provide their visitors with a higher‑fidelity experience. In turn, this drives web design trends with an uptick in full‑screen (heavy) background imagery or videos and more widespread use of hypermedia where traditionally static imagery and text would have sufficed.

CSS and JavaScript also contribute to page weight and browser work. HTTP/2 can multiplex requests over one connection and compress headers, reducing some of the overhead that encouraged aggressive bundling under HTTP/1.1. It does not remove request‑management costs, transferred bytes, or the work of parsing and executing the response. Measure the production page before deciding how to split or combine assets.

Our websites are getting more impressive and the designs are getting more complex. Animation libraries like GSAP and ScrollMagic (not that you necessarily need either to achieve the desired effects) are more ubiquitous, and even simple things like form inputs are becoming more reliant on animation to provide a more engaging user experience.

This, in and of itself, is no bad thing really; it's great that the internet and designers are freer to create more interesting, engaging, and impressive experiences. However, if we are looking at just the environmental aspect of the internet, then it is a bad thing ‑‑ at the moment.

When a user requests a webpage, any files not already available from cache must travel from a server through the network to their device. The route and amount of work depend on where the content is served, the network and the cache state. Each part of that system uses energy, but its consumption does not increase in a simple fixed ratio with every extra byte.

A heavy page can mean more data to transfer, media to decode and JavaScript to execute. I'm sure we've all visited resource‑heavy sites that leave the laptop fans spinning. That is a useful prompt to inspect what the page is doing, rather than a measurement of how much carbon it has emitted.

Users want pages to load quickly, which gives us another reason to avoid unnecessary downloads. Image formats such as WebP and AVIF can reduce transfer size for a suitable image and quality setting. Video projects such as WebM address a similar problem. Check the result, browser support and decoding cost rather than assuming a format change always makes the whole experience cheaper.

There is also a suite of tools to help optimise, minify and otherwise compress your CSS and JS files, but the data shows that there's still some way to go with all of these optimisation and compression methods if we want to keep the current trends of design and development innovation going.

Reducing unnecessary page weight can reduce transfer and processing work, and often helps loading time too. The energy and emissions saved depend on the devices, network, caching and electricity supply. A smaller download is useful evidence of less data, not a carbon meter.

The Data Centre Dilemma

On the other side of the equation, the servers and data centres that host our websites are a significant source of pollution and emissions themselves. Keeping the lights on, the servers running, and the temperature down; it all takes energy.

The IEA's 2019 analysis estimated that data centres used around 1% of global electricity in 2018. It also showed why global and local figures differ: efficiency gains had limited global electricity growth, whilst concentrated data‑centre demand could put much greater pressure on an individual country's grid. More demand for computing does not automatically mean the same proportional increase in electricity use.

With more businesses than ever relying on cloud computing to host their data and run their services, as well as more websites being created and hosted every day, the growth of data centres doesn't look like it'll be slowing down anytime soon. This means that data centres and the people that run and own them need to take other strides to reduce their carbon footprint on the environment. There's some good news on this front, with a few massive players taking steps towards being Net‑Zero.

In January 2020, Microsoft committed to renewable‑energy contracts covering its electricity needs by 2025, alongside a separate goal to be carbon negative by 2030. Its September 2020 partnership with BP includes renewable electricity supply and Microsoft cloud services. BP's stated ambition is net zero by 2050 or sooner. Those are different commitments with different deadlines; they need to be judged against delivery.

How Can You Help?

So, with all that being said, what can we ‑ as relatively lowly cogs in this particular machine ‑ do to help slow down the climate crisis and be more environmentally friendly?

For starters, we can work together to press the companies contributing to the climate crisis to change how they operate. Voting with our wallets and petitioning governments are part of that. Small changes to a website can help, but they do not replace action on the larger sources of emissions.

With that said (and wishful thinking aside), there are some changes we can make as developers, designers, or agency owners that can help lessen our carbon footprint.

What are You Developing?

What are you developing right now? Are you working on a website or web app for a client? If so, look for ways to simplify the end product to ensure it is as lightweight as possible and doesn't contain huge resources, tonnes of calls, messy code, or unnecessarily complex functionality. Another step you can take right now is to ensure you're keeping your images and videos short, correctly sized, and compressed as far as possible.

Refactoring away unused code can help page speed, which is usually an easy benefit to explain to a client. In February 2020, Danny van Kooten estimated that removing a 20 kB dependency from Mailchimp for WordPress could save 59,000 kg of CO₂ per month. His calculation assumed deployment across two million sites, 10,000 monthly visitors per site, a transfer‑energy factor and an electricity‑emissions factor. It is an illustrative model, not a measured global reduction, but it shows why a small dependency can matter at scale.

On top of this, think about what you are storing and deploying. A pet peeve of mine is seeing node_modules committed to Git without a reason. Normally, keep package.json and the appropriate lockfile in version control and install dependencies reproducibly. Deployment is a separate decision: a server application may need runtime packages, whereas a static site may need only its built output. Ship the files the application actually needs, and check that pruning dependencies has not broken it.

If you have the opportunity, work with the team and stakeholders to keep the product only as complex as it needs to be. Removing unused work can help both performance and resource use. You do not need to build a text‑only, 1990s‑style site, and you should not sacrifice accessibility or useful functionality simply to make a transfer‑size number smaller.

What is Your Company Doing?

It is not just developers that can have a positive effect on their emissions; the wider company that they work for can do things to help too. I'm sure we're all too familiar with the Cycle2Work schemes that are in place in seemingly every company nowadays ‑ and as annoying as it is to see that listed instead of a potential salary, they are still a great scheme to help keep the company's carbon footprint down.

It's also worth having a wider conversation about informing your clients, designers, and developers on what they can do to make the products you're developing more environmentally friendly ‑ or even to change hosting providers to companies that provide better, more green hosting.