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
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.
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.
And now for the stuff that we developers can actually do something about!
InterscetionObservercan replace scroll-scripts in many cases
MutationObservercan greatly minimize DOM-related work
ResizeObservercan achieve much better performance than
PerformanceObservercan help you measure any of these scenarios
The same components can be achieved with just HTML and CSS.
The most important thing you can do to lower your website carbon emissions, is by reducing the network-traffic on your site.
A quick win-win is by adding
loading="lazy" to all your
If a user only sees the top half of your site before clicking on another page, why load all the images below-the-fold?
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
<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:
So, if your screen is minimum
1850px wide, you'll get the
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
1199px, it will find the image closest to half of that:
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
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
- The video leaves the viewport
- You go to another browser-tab
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!
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!