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.
-
InterscetionObservercan replace scroll-scripts in many cases -
MutationObservercan greatly minimize DOM-related work -
ResizeObservercan achieve much better performance thanwindow.onresize -
PerformanceObservercan 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
autoplayenabled - 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!
Top comments (6)
Great post... something I was concidering myself. One additional thought, not to overcomplicate things is image format type.. most modern browsers finally support the webp image format.(apple finally catching up with the latest safari) I've switched most of my png files over to webp, but have fallback logic to use png if the browser doesn't support it. Real world I've seen about a 1/4 size difference between png and webp. Then there is svg which can be even smaller and render fantastic at any size, but it comes at a cost of render processing as it's nothing more then a math formula. Then there is always the default jpg, which works great for photos, but may not be your best choice for graphics or logos. It's interesting how much bandwidth can be saved when taking the format of the picture into consideration
Thank you! You're right: modern formats like webp (maybe not modern any more, it's been 10 years since it's initial release!) and avif can greatly reduce loading times. This article has some great image-optimizations outlined. For CMS-based systems, it's often easier to use CDN's like Akamai or Cloudflare. A content-editor uploads a full-size JPG, and these services will return the most optimized format (maybe webp), based on the browser-capabilities.
Really awesome advice in this post. Thanks so much for sharing!
Thank you!
Thank you! And thanks for the great links, I'm going to take a look at Gerrys book. I want to create a "this page use x amunt of co2"-JavaScript-snippet. Tom Greenwood shares the "recipe" on his site (from kb to electricity to co2), although I think the actual internet-electricity usage is way bigger, if you include routers, modems etc. Hopefully I can find some collaborators among the "sustainable crowd ;-)
Thanks for a great post! I'm all for making small sustainable choices all the time.
So makes sense to extend that to how you build and host your website as well.