Did you know that any website (including yours) produces CO₂ ⛽🤔?
A couple of years ago, we interviewed Xavier Vásquez: The Future of Research
Xav...
For further actions, you may consider blocking this person and/or reporting abuse
My personal experience has generally been that SPAs are almost always less efficient. A traditional website renders content on the server side and sends that to the client as HTML, a language it can parse and render natively and has had decades' worth of performance optimisations to process.
SPAs, on the other hand, first have to send a (typically large) JavaScript file to the client that must be parsed and executed, just to manage things like hydrating content and page navigation that the browser does natively. Any content is then sent as JSON, a language that has to be offloaded to JS to be parsed, before the page is built by the client.
A good rule of thumb for performance (and carbon emissions, as the two often go hand in hand) is to use browser native functionality wherever possible. Endlessly reinventing the wheel for the sake of perceived developer convenience is rarely better for performance. There are, of course, web applications that do work better as an SPA, but it's a mistake to try and build traditional websites this way in the belief it will improve their performance.
There's a guideline for this in the currently draft W3C Web Sustainability Guidelines: 3.23 Take Advantage of Native Features
TLDR (lol) but anything that's client code has two big measurements:
To deal with the former make sure you run through a bundler adequately configured to minify your code, make sure the server has the compression enabled and so on.
The later depends on how efficient the device running the site is, E.g. a macbook M2 will waste way less energy than a macbook i9 to load the same website.
Of course, if you go the SSG way you'll find benefits in both 😁
They are good topics, but here we're coming to a couple of things, can you modify your server? What if you cannot? I see it from the final users' perspective, they might have hired a hosting for X period of time, and they can only upload their stuff. They have no control over their infrastructure. In this case, you cannot create a better cache since you rely on your provider. Indeed, you can always change providers, but that means to reconfigure everything. I don't think it's the right way to go.
Where do people run your website? I'd say most of them expect to run them from their phones. So, it will be a similar case to the MacBook M2, but similarly, you can upload considerable images, and the result will be that your website is heavy and slow, increasing its carbon footprint.
I mean that there's correlation here, if everybody uses more efficient devices and everybody tries and reduces the size and computational complexity of the software as much as possible, we'll reach the peak in that subject.
PD: even if you cannot modify your server because you got a shared hosting (which accounts for 37.64% of the hosting market share as per demandSage statistics) you can use an external service to cache your statics (a.k.a. scripts, images, videos, html files...) e.g. Cloudflare
Do you have any tutorial on how to upload the files only to Cloudflare? I was able to create one, but I was able only to move only my entire website, not only the scripts or images.
You don't need to "move" your files into it.
You can have the website somewhere else and configure your DNS so it is Cloudflare the one answering the requests to your website. Cloudflare will then answer the request with the most recent cached version. It will handle the cache automatically for the most part.
Learn more here 😁
It's an interesting thought, but what if your client only has an S3? I have a friend who faced that limitation. How do you deal with it? I'd like to know your thoughts.
SSRs are an amazing solution when you have your own hosting or have your own server, cluster, etc., which involves certain costs that not everyone wants to pay if they were considered in the beginning. That's why, I focused on what I could fix without moving to other providers or solutions.
Great post! Lazy loading pagination is another useful technique to reduce requests to the server. When the user wants to go back to previous pages, the past results are already there, so the server doesn't have to send them again.
Indeed, I did something "similar," I loaded on demand the sections based on the scroll location. However, that's not something so "visible" for the calculators. From what I can see, they fully scroll your website to analyze the full impact. Or maybe you can share with us your technique. It will be worthy to know it, Ahmad. Thanks!
uhhh, cache-control headers?
If I could configure GitHub pages, it would be a great solution, but I cannot.
Thanks for sharing. It’s one of the great subjects on the table in 2024. I did some tests with each one, and there are my resume:
A good similar tool in french: ecoindex.fr/
The French one seems quite odd or even "fake" or even lower quality. I have tested many solutions and the results are crazy:
Page Rank:
168240 / 250135: Too heavy
1,432 MB: Too complex
778 items: Too many requests
131 requests
ecoindex.fr/resultat/?id=792f0978-...
I don't think the results are quite accurate since it took almost nothing to analyze it and the results are drastically different from any other calculator.
Hmmm strange. For the test I did the result was quite similar to the others tools - except websiteemission. ANd quite logicial, as well.
Let's think about a balance between results of different tools, it's probably the best way to deal with.
I tried 3 websites that I know. Two are hosted in green hostings and mine (normal hosting AKA GitHub Pages). All other calculators got similar results, but Ecoindex.fr was extremely different. Furthermore, it didn't make anything clearer to me and its suggestions were not exactly very useful.
Ecograder, on the other hand, suggested to me very specific actions to take, for example, a certain CSS (Bootstrap, for example) was not optimized, or a specific JS was not minimized.
I would say between the common calculators and Ecoindex.fr, there are widely unrelated? standards since their conclusions are considerably different. For example, Ecoindex.fr highlights the number of elements that websites have.
This is something that none of the other calculators mentioned and is difficult to fix in most cases. You can run Lighthouse to analyze your website's performance, and I've never had a recommendation that told me, "Too many Divs! Remove some of them!" It's a very strange standard to consider. Also, it was the only calculator that did not mention the lack of Green Hosting on my website. This was very odd. I personally cannot recommend Ecoindex.fr for now.
My conclusions, for now, would be:
Here are my results using most calculators:
Sources:
Yes, as I said it's strange. I did the same test with my own website, and the results was differents, but not at this point. And the badest there was websiteestimation. Anyway. After, I'm not completely with your remarks against ecoindex about the complexity of the DOM, because it's an indicator. That's said, I don't know exactly how it's used in the ponderation, so...
I even checked a heavier website that I know and the results were as bad as mine. I think something is wrong. Both of us ranked E. It made no sense. Also, I don't know why my website will be 1 Megabyte and something. It's odd.
Thanks for this article. I checked it out, and although I am not scoring badly, I can make some improvements on my website.
I'll pick this up sometime soon.
Share your score! It's good for everyone!
love the content... wrote something similar blog
You might add greenwashing. The automated audit tools put a green check mark for supposedly green hosting on so many websites that run on international clouds unlikely to use no fossil fuel in any country. You might also add micro-optimization. Audits like lighthouse / page speed insights always have some nitpicking left, including dubious advice that might backfire, and so do some manual optimization checklists. And as others already said, "modern technology" like SPAs and AI can also rebound and waste more energy than it will ever save.
Nothing is perfect, and there will be always biases. You might skip or one two things. The same will happen in anything in our world. I remember when I was in charge of building the first recommender system for taxes in a company. In some countries, a bottle of soap had many things to be taxed and in others fewer. Therefore, some countries were greener and others less clean. However, I won't jump to the conclusion that is full greenwashing. If you can minimize your code and make it faster, then it's saving resources, therefore, it's cleaner.
About SPAs and AIs, you're mixing two topics as one. In my analysis, I considered SPAs more efficient mainly for complex apps. I didn't build my website with Angular or React, and I don't think it will be a good practice since it's not a complex app. It has a certain complexity since I create many things dynamically, but I don't have multiple pages, log-ins, etc.
When I spoke about AI or LLMs, I focused on how GitHub Copilot or ChatGPT can help you identify code that can be optimized faster. Visual Studio for example has a powerful feature called Intellisense. It was introduced decades ago. It analyzes all your files and helps you remove redundant code while optimizing it. What's more, you don't need all files in one to analyze (if all is correct). This is where I can see LLMs can help you. Let's say you have a large website, how do you know where you can optimize something? At least, I don't everything about JS or CSS (especially yearly changes), there might be something I'll forget or it can have a considerable impact, but I didn't care about it. Not optimizing this code can have considerable consequences if your website has a large traffic. The less technical debt we have, the more efficient it will be.
Any services running on AWS Region Canada Central will be green, as the data center, if I recall correctly, is located in Quebec.
94% of Quebec is powered by hydro-electricity.
Yes, but I'd not focus on that point. The Green hosting is not the solution to any problem. I have analyzed other websites that are green hosted and are F. Why? Because they don't follow any standards. Also, moving to a green hosting can have consequences if your client (or you) have a contract with the hosting provider. You cannot always cancel a contract without repercussions. In my case, I could move it anywhere, but that's not for everyone.
Good point. Thank you
Making an SPA does not make a page green? It just causes bloat. Unless you're making an advanced app, the only thing and SPA does it waste resources. And with all due respect, but how in the name of all things holy could making an SPA from what you already have be automated?!
Using AI to make the webpage more environmentally sound is paradox in itself, since the use of LLMs eats a lot of processing power, i.e. wastes energy and burps out CO2.
You also seem to miss that the heaviest resource on the internet, and the one that has ballooned the last decades, is js. It's not images. SPAs are full of JS, unnecessary JS that does things the browser already does.
The first point can be fair. It depends on what you need, I'm not saying that for a personal website, you should use Angular or React. I built my own website with HTML, JS, and CSS only.
Second point, how do you know which sections are not optimal in your own JS/CSS code? How do you know how to optimize them? At least I don't everything and can forget one thing that can become a bigger piece of code that GitHub Copilot or ChatGPT can catch faster than me.
Indeed, the first time, optimizing code using Copilot will consume more resources, but if your website is visited a lot (thousands or millions of viewers per month), then, it will save more resources in the long term after the optimizations. Again, I don't know all the JS/CSS changes over the years and cannot know them. This is where I see the benefit of using LLMs to improve my code efficiency.
My good old portfolio has an A+ (0.05g/visit) 😂
I assume it's due to computational load, it's a static site with almost no JS in the dist (CSS Only approach whenever possible).