Skip to main content

← All videos

A developers guide to low carbon websites

September 15, 2020
Tim BenniksComposable architecturePerformanceCloud & infraFrontendMedia production

This is my ImageCon 2020 talk.

How to make more sustainable choices in the production of web technology. This talk helps developers to make changes to their code so that their website has a lower carbon footprint.

If the internet was a country, it would be the world’s sixth biggest polluter. The internet consumes a lot of electricity. 466TWh per year to be precise. That’s more than the entire United Kingdom (300TWh)!

Carbon emissions are generated all over the place, from data centers to our personal devices. The average website produces 1.76 grams CO2 per page view. For a website with 10,000 monthly page views, that's 211 kg CO2 per year. These are staggering numbers and they will only go up as the internet is growing at a frightening rate. To make the internet more sustainable, web developers have three areas of attention.

1. Design and content 2. Front-end development best practices 3. Server architecture choices

Transcript

hello my name is Tim Mannix and in this image con talk I'll be going over the best practices of building a website with a low carbon footprint the environment is super important and as it turns out websites are pretty big offenders in having a big carbon footprint or a high carbon footprint with a lot of emissions we cannot have that we have the knowledge around us so let's just pull it together and build proper websites that are good for the environment um in this talk we'll be going over all the details so let's kick it off alright let's dive in the title of today's talk is a developer's guide to low carbon website or to precise it a little bit more how to make more sustainable choices in a production of web technology I hope that after this talk you'll have this unagi so for the uninitiated here Ross in a TV show of France thinks he has the unagi state of mind which is basically he's aware of everything around him um so let's talk about me for a second my name is Tim Mannix I come from Amsterdam I was born in Amsterdam and now I live in Paris here in Paris I am the director of web development at Alltech and I'm also a proud member of the media developer experts at cloud Andheri so without statistics a talk about the environment doesn't mean that much to me so I thought let's dive in and give you some numbers so if the internet were a country it would be the world's sixth biggest polluter oh my god so when I did the research that was my response as well it's like wow that's that's amazing um so turns out the Internet consumes around 466 terawatt-hours per year keep that in mind and then see that the UK only consumes around 300 those are staggering numbers so the average website produces 1.76 grams of co2 emissions per page view so for a website that has around 10,000 visits per month that's a staggering yeah I say the word again 211 kilograms of co2 per year um this is crazy we need to do something about this so we I've scoped this talk a little bit more towards a development production team and what they can do to make this better so I have identified three areas roughly in which we can work first UX and design second front-end development best practices and third architecture choices so with before we dive into the tips and tricks in the details let's have a look at your website go to website carbon comm fill out your URL and have a look what comes out I'll do it now for mine so this really is a great website the guys behind this I did a bunch of research and if you go here you can actually see how they did that and how they calculate everything so let's type in my website it's there already here we go so calculate so as you see I'm doing this life so I just released my new website so let's see it might not be as good as I hoped or of course I tried this before but maybe they actually changed their algorithm but I think now it's still the same so basically my website is cleaner than 90% of pages tested that's pretty cool I did however take a lot of time to build my website with all the rules up I'm about to tell you in this video so I only have a 0.1 two grams of co2 I'm rather than the Ridge 1.76 that we just talked about so and also I made the choice to have sustainable energy for the hosting I'm using more on that later so basically I would be creating almost 14 kilograms of co2 in a year if I had 10,000 visits per month or I would have enough power to boil 1884 cups of tea that's fun one tree this webpage emits the amount of carbon there's one tree absorbs in a year anyways let's get back to the talk but when you have you have some time check this thing out because it's super cool all right let's go into the first category UX and design and content look I drew a sketch of how we're gonna do it okay Rach that's you that's the couch oh that's me yeah so UX right it's always a committee it's complicated whatever so why did I choose this subject because actually shitty accessibility and UX are pretty big offenders on websites that have a high carbon footprint so if you make sure that your accessibility is spot-on your SEO is spot-on your content is very readable people are in and out very quickly and therefore they'll have a lower carbon footprint so if your page is easy to find if it's also easy to understand people just use their devices less right there's much less resources going over the wire if you can find something the first try rather after six tries right so next to that in the content make sure you convey your message in as little content as possible and sometimes that doesn't work or sometimes you have your have to whip your story terms into place a little bit of like you might want to tell a 10,000 page story but it can be done in two so talking about whipping it's not whipped whip this that's what I did anyways I just wanted to put this scene in because it's so much fun and also you kinda have to whip your designers into place to understand all the technology storytelling content everything together right I don't say whipped as a developer just everybody together needs to be on point and so if you want to go a little bit more technical the rough tool you can use to cover all your basics is the web developer tools in Chrome and use your audit step and just run an audit you get a lot of bases covered that way um so let's jump into accessibility this is a pretty big one that we need to deal with if people want to find your content quickly your website better be accessible so what can you do for accessibility as a developer first of all have your code compliant to a or AAA standards I say code compliance not compliance because compliance itself requires an official agency to give you the stamp of approval and do that over time that is very expensive there's a lot of effort there and it's also not always objective between Europe and the u.s. things are different so if you go code compliance so have no errors in your code you have done a pretty big step already um also make everything relative I don't want to see pixels anymore we're only doing EMS ramps percentages stuff like that and I'm saying this because a lot of people soon their websites and most people that need like have a disability and need to see something better they zoom like 200% but sometimes your fonts don't zoom as nicely as your interface or whatever so if you put everything together with relative elements of relative EMM stuff like that it will grow properly and what one thing you have to worry about here is if you go and zoom by 300% on a big desktop screen is actually showing you a mobile interface so make sure that your mobile design works with keyboard as well as a hard one but it's you should pay attention to that next SEO arguably more important than accessibility for easier finding of content so this is a list of stuff and if you implement all of those you have again your basics covered extra stuff is again an agency that can help you but just make sure you have your basics covered and if you don't know what these are I won't go into them in depth now because we only have half an hour but just google them and go from there so make sure you have a canonical URL if a proper title and description for the page have a sitemap XML have schema.org rich data have proper og text have no 404 or 500 errors use HTTPS secure connection and have semantic HTML and have a correct page outline if you have all of those in place you will no longer be on page 2 on Google where everybody dies you will be on page 1 the only thing you have to now do is make sure your content is good so but I want to engage my users for as long as possible I've heard so many clients of mine say that I want him to stay on the website consume my content but are you Facebook probably not right you there's probably not really a reason for people to browse like 25 products of you that they weren't looking for so I'll let Joey explain it right because if he doesn't like you this is all a moot point a moot point yeah it's like a cow's opinion just doesn't matter its Moo he speaks truth but I know your boss likely told you my goal is to have people as long as possible to consume my brand so if that's the case and you cannot fight back which is normal that's the way it goes sometimes um at least follow the guidelines for performance that we'll go into now let's talk web development best practices as all web developers love to discuss me included so performance on the front end has a big impact on the carbon footprint of your website it's also one of the most visible ones and it's the easiest for developers to tackle um so not even three years ago the average page was around four grams of co2 emissions per page load nowadays it's already down to 1.75 so over the past couple of years we've done a great job getting better at this we're still not there yet however so let's talk about what the biggest offenders are for a webpage that doesn't have a low carbon footprint and generally that's the stuff we cannot really control in the development team so think about third-party libraries and Beth's media assets JavaScript personalization tagging systems like that generally they are poorly optimized because they have to work everywhere so they first have a lot of features and they are bulky and they might not use green hosting and you cannot control that right and that's a big part of having a low carbon footprint so what I would say is eliminate bloat that's the only thing you can do to not have this so really be selective of what you use or try to remove as many third-party dependencies as possible and that's not always possible of course but in your own team you can so do you really need all of lo - or underscore do you need moment your SJS with all its languages you need modernizr jQuery UDS react do you need all of it probably some of it but not all so really be vigilant on what you use and if you do have to use a library make sure it's modern and it supports import and export statements because then web pack is magic because you can say just load this part of that whole library and then when I compile my code only that small part is in your compiled code and not the whole library because bigger file size means more bytes over the wire means more work for your device which means higher carbon footprint so have less eliminate bloat actually bloat wise I would say Google tag manager for analytics and front-end personalization engines are the worst so I'll go over what they do because Google tag manager is like an analytics tool that is really smart because you add a little bit of script on your website and then Google in its dashboard environment where you can select what kind of analytics you want you can inject a whole bunch of code to deal with the website because there's a JavaScript file there so it has access to the Dom of your website so people add in stuff all the time to do their analytics job but generally those people are not in your team so you don't have control over what they put in it's a similar thing for those personalization engines so basically there's another company that looks at a be testing or stuff like that and they would actually say okay this user has that cookie that session I'm gonna inject this big chunk of HTML or I'm going to add this bunch of CSS and generally the files that those systems come with are pretty big they are really big offenders I'm wearing everything you are that's what they bring basically so and then so it's generally people who are in marketing who are really skilled at their job but don't actually know anything about as developers so they blowed your website through those systems and they have no idea that they just added jQuery a blah blah blah you just have one click handler they didn't realize that so when your website goes live as a developer you're happy and then a month later to check and you get this I've had a diamond time again when I check a week or a month after go life and suddenly my performance is down the drain because somebody added a bunch of stuff through google tagging manager so controversial point most brands only use 5% of Google tag manager and personalization engines like they have so many features they are so advanced but a lot of companies are not there just yet not everybody is Amazon right maybe it's not worth the bloat I understand that you have to but with this information you might be able to challenge that and have a lower carbon footprint so next progressive enhancement this is more of a way of working where you build the most simple set up and in base of the features of your visitors device you can add some fancy features on top of that experience with generally lead to not so much code and then you have the other side of the equation graceful degradation which is I will build my blue sky fishing with all the fancy features for the newest browsers with everything in place and then I'm going to check for older browsers that are not as capable and add extra code to degrade gracefully so they have also a good experience but generally that means there's more code and so progressive enhancement has less code which means less data over the wire less data for the processor of your device to interpret so less energy consumption so lower carbon footprint use this to build your website then one of the biggest of all is media optimization managing video and images is really hard but the concept of what you have to do is fairly simple let's have a look so optimized assets to have the smallest file size the correct file type and the correct resolution and do this for each context that they are used in this means that if you have on your mobile device you want to your and let's say the Chrome browser and you want to show an image full width that means the resolution is around the size of your device and the file type is probably web P because it's chrome um and you have optimized it to a certain quality so you don't really see the bad artifacts on your small screen but then when you go to Safari on a big screen the file type is going to be different the optimization is also going to be different because on a big screen that's a Retina screen you might see something differently right quality wise so for context optimize the image to exactly what it needs to be don't have extra stuff to download so but so that contexts or that that idea is pretty simple right but then you actually have to do it and this is where we I feel like we're just incapable it's it might be too hard with all the factors put together every project we have to figure this out again and every time I have to explain it I have to look it up myself again it's kind of funny right that's on the one end we have Google stadia which is the new gaming platform by Google where they basically can stream 4k footage 60 frames per second with low latency while you are playing the game as a user through a browser right this is like the peak of technology at the moment and on the other hand we cannot even show a simple image because that PNG that should have been a JPEG is 4 megabytes and it's stretched I've seen many websites with this like how can we be so advanced in one end and so not as fans in the other we really need to step this up um so you can try to DIY your own like optimization pipeline that also resizes images and stuff like that I've seen a lot of companies do this but it's very expensive its time-consuming and you're always kind of behind because you have sass platforms like Clara nari or like twit pics or like image IX and there's a bunch more that actually have done all that homework already it's their business model to manage media for you so it might not always be a digital asset manager like a dam even though some have it but it's more about the delivery and that's one of the hardest bits so they are cheap just use them and have such a big improvement in your performance so next lazy load all the things including the images we just spoke about so if a user doesn't use something at that point in time don't load it there's no need for them to waste the resources if you have a mega menu that pops out and when it pops out there are some images don't load those images on page load because most likely the user is not going to open that menu because through Google they found already what they were looking for because you had good SEO don't load those images so only when the user needs it don't waste resources do we dare we did so Joey and Chandler are actually chilling on their lazy boy chairs here so lazy load all the things as much as possible so images video iframes third-party libraries and by third-party libraries what I mean is if you have to load let's say a YouTube embed or you have a system like bazaar voice that has refused ratings come and stuff like that if you load that on page load and you put the script in the header the page weights loads the script in and does a bunch of stuff and generally does things like let's say that the comments are on the bottom of the page just let the user scroll down and when they come to the place almost where those comments needs to be then loaded in because there's quite likely that they will never see that part of the page so don't load it yet one thing though is really beware of gdpr because sometimes some scripts have to be loaded to check if there's an opt-in or somebody gave consent with their cookies so don't lazy load so much that you are not compliant to gdpr anymore that's actually very important all right check out this bad boy 12 megabytes of RAM 500 megabyte hard drive built-in spreadsheet capabilities and a modem that transmits at over 28,000 bps olden 90s they were awesome anyways let's talk about server architecture and making the right choices there so I think our current model is pretty bad for the environment and lately a lot of different models have been popping up and I think they can help us here so let's talk about those but this is what we have at the moment the monolithic application so that's basically one big juicy package that has everything from web servers to CMS to extra services to databases to your whole front end everything is in one big nice package as you can see there's a bunch of arrows in between so there's a lot of activity going on everything is always on it keeps state of each other it knows and it's just this one big beast that spits out an HTML page basically there are some issues here so I won't go too deep but let's go over them quickly so cost performance security power consumption and scalability cost mainly because there's a whole bunch of special stuff within that big package and it's always on it's expensive type of stuff that you need that always needs to be on for every page that you hit something happens there right so that's just an expensive approach also performance these things can really perform but generally when you have a it has all this dynamic stuff behind it with the surface and you click on something needs to go all the way back into that thing and come back to you and give you something and generally now we have this optimized but there's a lot of energy involved in doing that and then security if you have such a big system there's a lot of surface area to attack if all those surfaces running at the same time and when you go into one you can probably hack into all of them not in not everywhere but this is possible think about WordPress or these kind of systems they're the most hex systems ever and they rely on this monolithic system I don't think in the future and nowadays they are pretty good but that is the history they have a lot of power consumption because like I said they were all on there constantly keeping state they're constantly that the power is churning right and then scalability so if you hit Christmas and we're gonna have to pay the big bucks to some company that helps you out to do load balancing and then having multiple of those environments up and running and crazy scaling stuff it's very complex it's not let's say it's not easy to scale and it's also not cheap so I would say gem stack to the rescue gems jack is not the savior of everything but for a big chunk of the websites out there it can really help so just like I said it's not for all web sites but it can cover a lot of them so gem stack is JavaScript API is in markup so the simplest thing how I can explain it I think is what you do is you have locally on your machine or in the CI the build system you build your code write that code is built and then you push it to get up so or whatever get you use and you have all your information in there and then app build state step that built it will actually take all your data and compile that into a static website so the dynamic bit the state keeping the complex stuff is only a built and then once it's been built you you leave what you're left with is a it's a like a chunk of files there's a bunch of files that are static HTML CSS JavaScript images form stuff like that then that would actually be put on a CDN edge so that means there is no origin server of which the CDN grabs the information to show that to users because there's no need for an origin because everything is static that means right now when I hit safe on my website it goes to github github then talks to net Levi in my case net device as hey there's a new change let me just rebuild that front-end get all the data in my case all the data comes from github but that could also come from other places it generates my whole website makes this nice little package of static files and put it on 30 places around the world for everybody to say em this is basically a very simple approach to go to the static and website which means if you want to scale this you have to put those files in different places or in more places there is no extra cost there there's no running services there's no origin it's basically decentralized and all the complexity is internal in my build system that's where I get my data and get stuff and I would say if you look at most websites out there they could run on the jam stack and especially if you add extra sass providers like having a headless CMS where content edits can still have the feeling of editing something and then when you hit save you would actually do that whole build system every publish and then output again a static website or you can if you have to have people logging in you can add identity providers you can add a whole bunch of third parties around it that makes til make this system a decentralized system and it performs because of that because if you use the identity provider a lot you only have to scale that identity provider not the rest so if you don't use something you pay less if you use more of something you scale that little chunk up and bail only there so this is kind of a nicer approach to the architecture system and I know that a bunch of my colleagues are rolling their eyes right now because I am working on global platforms that sometimes have 200 websites under the same umbrella that all reused their girls and there's very complex personalization going there's all this stuff I know guys I work on them every day but there are still ways that we can actually get this stuff to work for example if you use uniform this is a company started by my friend Alex Chiba who used to work at sidecar and knows that system really well and now they have built a shell in front of those big systems that can actually make it a gem stack website so I'm not saying this is like the unicorn out there it's perfect definitely not there are still use cases that warrant you to have such a big enterprise system clearly but again probably 80 to 90 percent of the websites out there can work on a gem stack alike approach so next one is look at something called surfer les it's kind of a funny term right but that actually grabs back on not having this origin server but having everything micro surface like this is goes as small as having a function as a micro surface in the cloud so it's a simple stupid stateless function that has an input and an output and it doesn't know about anything else and if you don't use it it's off when you use it it turns itself on and only then you pay for it so you can actually do simple actions completely decentralized with these things and if you do them a lot you can just scale those things a lot but only that one so basically you can connect them all up if you want to and you have to orchestrate them and then you have profit because it's such a nice approach to building an architecture in the cloud um of course guys there is an elephant in the room here that we didn't talk about yet which is server parks you know those server parks that are underground they need cooling they need security they need protection they need redundancy backups there's so much power going through the things by default CD ends and server part don't have a low carbon footprint so if you do use any of this try to find one that puts itself as I am a green host or a green CDN and that doesn't mean that their servers are green but they are most likely carbon positive as a company or some sort of thing to offset it and there are some server farms that are actually lower in carbon footprint so make sure you choose those and also make sure you persuade your clients to use the same because in my case where I work we have those big infrastructures that clients already have and we work on them we cannot always choose but make sure that you persuade your clients to actually change it all so we are have a better environment in ten years hopefully are not worse so let's conclude actually based on what I've just mentioned it's not that hard you know the concepts are easy to grasp so follow general UX and SEO guidelines follow performance guidelines reduce the bloat and deal with media assets choose the right architecture and choose a green house or CDN and that's it guys it's not that hard but all of it together of course has some effort so I hope this video helped you to at least understand what needs to be done and good luck building your websites see ya