We've all heard about the Paris-agreement.

We've all seen Greta Thunberg, fighting for climate-change, week after week.

We've all seen the devastating forest-fires and how climate-change is ruining our home-planet.

But what does that have to do with web development?

Should you as a web developer do anything, apart from putting your PC/Mac to sleep, when you leave it for lunch?

Well, it's relevant for everyone, but it's actually really important for web developers, because we develop websites for the internet — that currently consumes 416.2TWh annually.

That's more energy than the entire UK!

According to Website Carbon:

The average web page tested produces 1.76 grams CO2 per page view. For a website with 10,000 monthly page views, that's 211 kg CO2 per year.

This is an important and complex topic, and there's no easy way or checklist with "just do this and you'll be fine".

But let's have a look at some of the things we can easily do:

Choose a green hosting provider
Choose a green CDN
Prevent battery-drain
Reduce network-traffic
Simplify the user-journey

Choose a green hosting provider

Are you using a green hosting provider with a strong environmental policy?

That's a tough one - how would you know?

Luckily, The Green Web Foundation knows, and you can check your site there.

If your site is green, the even give you a nice badge (!):

In their direcory you can find a list of hosts in countries all over the world. If your host is not in the list, you should contact your host and ask them if they have an environmental policy and/or is doing anything to lower their carbon emissions.

At Sustainable Web Design you can find a list of relevant questions to ask, when chosing a hosting provider.

One that I find particular interesting is:

Is the hosting located as close as possible to the core user base?

Why is this relevant? To transfer data consumes electricity, so the shorter the distance, the lower the cost.

Choose a green CDN

For CDN's, almost the same principles apply, as when choosing a hosting provider.

You shouldn't have to worry about the location of the CDN, as most of them have locations all over the world, and thus will place your data close to it's core user base.

If you do not have a CDN, it might be beneficial for your site, depending on the number of assets your site has. Big CMS-systems like Sitecore and EPiServer are not always very good at handling large amounts of assets / streaming content.

The advantages of using CDN's (although there is an extra cost) are:

Returns latest image formats, even if an editor uploads an image in an "old" format
You can query an image with a w-descriptor for responsive images (more on that later)
You can stream inline html <video>s. Most servers are not streaming servers and will download an entire video before playing it.

Prevent Battery Drain

And now for the stuff that we developers can actually do something about!

JavaScript- and assets-heavy sites drain device-batteries faster than super-slim and fast-loading sites.

JavaScript have a suite of Observers that can greatly affect the performance of your site.

InterscetionObserver can replace scroll-scripts in many cases
MutationObserver can greatly minimize DOM-related work
ResizeObserver can achieve much better performance than window.onresize
PerformanceObserver can help you measure any of these scenarios

I love JavaScript. But I only use it when it's absolutely necessary.

A lot of the components you see around the web use JavaScript unnecessarily.

The same components can be achieved with just HTML and CSS.

Tags like <details> and <input type="range"> can, with very little styling and/or minimal scripting, be used for really engaging UX.

Reduce network-traffic

The most important thing you can do to lower your website carbon emissions, is by reducing the network-traffic on your site.

Add lazy-loading

A quick win-win is by adding loading="lazy" to all your <img>-tags.

If a user only sees the top half of your site before clicking on another page, why load all the images below-the-fold?

Use Responsive Images Correctly

Responsive images are tricky, and many sites are not using them correctly. That's partly because many CMS's have just one way of returning an image, unless it's a custom built component.

First, you need to be enable to ask the server for a specific width, using the w-descriptor:

<img alt="alt text" src="https://your.cdn/img/IMAGE.jpg" crossorigin="anonymous" decoding="async" loading="lazy"
srcset="
    https://your.cdn/img/IMAGE.jpg?w=250 250w,
    https://your.cdn/img/IMAGE.jpg?w=450 450w,
    https://your.cdn/img/IMAGE.jpg?w=650 650w,
    https://your.cdn/img/IMAGE.jpg?w=850 850w,
    https://your.cdn/img/IMAGE.jpg?w=1050 1050w,
    https://your.cdn/img/IMAGE.jpg?w=1250 1250w,
    https://your.cdn/img/IMAGE.jpg?w=1450 1450w,
    https://your.cdn/img/IMAGE.jpg?w=1650 1650w,
    https://your.cdn/img/IMAGE.jpg?w=1850 1850w"
sizes="100vw" />

But that's just part of the puzzle, because the code above assumes the image will always be as wide as the screen: sizes="100vw"

So, if your screen is minimum 1850px wide, you'll get the 1850w-image.

If it's a hero-banner, that's probably fine. But if it's an article-image, shown in a 25%-width grid, it's 4 times larger than needed!

Remember to use the sizes-attribute correctly — as an example:

<img alt="alt text" src="../assets/img/IMAGE.jpg" crossorigin="anonymous" decoding="async" loading="lazy"
srcset="
    ../assets/img/IMAGE.jpg?w=250 250w,
    ../assets/img/IMAGE.jpg?w=450 450w,
    ../assets/img/IMAGE.jpg?w=650 650w,
    ../assets/img/IMAGE.jpg?w=850 850w,
    ../assets/img/IMAGE.jpg?w=1050 1050w,
    ../assets/img/IMAGE.jpg?w=1250 1250w,
    ../assets/img/IMAGE.jpg?w=1450 1450w,
    ../assets/img/IMAGE.jpg?w=1650 1650w,
    ../assets/img/IMAGE.jpg?w=1850 1850w"
sizes="(min-width: 768px) and (max-width: 1199px) 50vw,
(min-width: 1200px) 33vw,
100vw" />

In this example, the browser will find the image that's closest to the matching media-query in the sizes-attribute. On smaller devices, it will find the image closest to the actual device-width (100vw), while on devices between 768px and 1199px, it will find the image closest to half of that: 50vw.

Videos

Like images, there's no need to load a video if it's "below the fold", and the user never watches it.

Videos need to lazy-load as well. Iframe-based videos (like YouTube or Vimeo) can use loading="lazy" like images, while HTML <video>s need to have preload="none".

If the user has Save-Data enabled, do not autoplay videos.

A video needs to pause when:

You click on another video
Another video within the viewport has autoplay enabled
The video leaves the viewport
You go to another browser-tab

Cache

The more you cache, the less network-traffic. Simple as that!

A CDN like Cloudflare has excellent caching, and you can control what to cache and for how long.

But you can also cache assets that do not change often with a Service Worker.

And while you're at it, make an offline version of your site as well!

Simplify the user-journey

My former colleague, Tim Benniks, has written an excellent article on sustainability, and one of his key points is:

We [normally] want visitors to explore the brand, linger and become influenced by the product story. They should become lifelong customers. Sadly, this goes against what is best practice for websites with a low carbon footprint.

So, we don't want users to spend too much time on a website!

Instead, we should focus on simplifying the user-journey.

I think everyone have tried to look for "shipping cost" on an ecommerce-site, and, not being able to find any relevant information, added an item to the basket.

With still no info on "shipping-cost", I've personally then filled out dummy contact-details until I finally reached a page with the calculated shipping-cost — which were then too high, and I abandoned the site!

I've no idea what the carbon emission footprint is for all these sites with miserable user-journeys, but I assume it's a lot!

Yesterday, A Book Apart, published a new book on the topic:

In Sustainable Web Design, Tom Greenwood offers a practical path to faster, more carbon-efficient websites that are not only better for the planet, but better for our users.

I've only started reading it, but so far it's excellent!

Thanks for reading!

Making Sustainable Websites