Decarbonization | minima.media

Every website visit causes a CO₂ emission of approximately 0.8g CO₂. This may not appear to be a lot, but the cumulative effect is significant.

0.8g CO₂ for a single page view may not seem much. But if all 8 billion people were to visit a site, it would result in CO₂ emissions of 6,400 tonnes. That's roughly equivalent to 3,200 intercontinental flights (return trips) over 8,000km in economy class. With the second click, it's 6,400 flights, with the third, 9,600, and so on.

Assuming that a tree can absorb about 20kg of CO₂ per year on a global average, it would take 320,000 trees to offset the CO₂ emissions of a worldwide page view. Not to forget that all is released again when the trees die and decompose.

All for a single page, without even knowing if it was read or just clicked away.

Analysis Tools

Anyone wanting to know the CO₂ footprint of a website can find out using one of the leading CO₂ analysis services. Simply enter the address and you'll know its footprint. It's a matter of seconds.

decarbonise

CO₂ Analysis Tools

There are various services for measuring the CO₂ emission of a website. Most are free, and some offer detailed tips on where and how a website can be optimised.

Website Carbon is suitable for anyone who wants to see how a website compares to others. The service analyses and evaluates the CO₂ emission of a website based on its size, complexity, and the servers on which it is hosted. Since December 2023, Website Carbon has been rating the CO₂ emission with an efficiency label ranging from A+ to F. The service was introduced by Tom Greenwood on the website of the web agency wholegraindigital on 22 May 2018.

Ecograder offers a very detailed analysis with concrete tips on how to reduce the CO₂ footprint. Like Website Carbon, the service rates the CO₂ emission with an efficiency label ranging from A+ to F. The service was introduced on 22 April 2013 by Mightybytes, a company in Chicago that specialises in developing sustainable digital solutions.

GreenFrame offers comprehensive analysis capabilities and immediate integration into the development process, allowing developers to optimise the ecological footprint of their applications step by step. It is a paid tool with many features and configuration options. GreenFrame was introduced in April 2021 by Marmelab, a company from Nancy, France.

Page Bloat

The first webpage in 1991 was 5 KB. Today, they average 2500 KB. The trend is upward. The term Page Bloat stands for web pages with more and more images, videos, and interactive or immersive worlds. How can the CO₂ emissions associated with them be reduced?

decarbonise

Page Bloat

Page Bloat describes the phenomenon of websites becoming larger over time through the increasing use of images, videos, extensive scripts, stylesheets, and other resources.

Unlike in the areas of housing and transport, CO₂ emissions in the web are shooting up unchecked, without being aware of it and taking appropriate measures. Yet, there are indeed efficient measures.

Omit

Although it may initially sound defensive: Omitting is not the worst option. The duration of a visitor's stay on a page is in the range of seconds. Images capture attention and often lead to not reading the essentials because  one thinks they have seen everything already.

Typography

Fonts cause shockingly high CO₂ emissions. Every font omitted,

Lazy Loading

With 'Lazy Loading', contents are only loaded when they are actually used, i.e., when website visitors scroll them into the visible area of the browser. If they are not reached at a low scroll depth, they are not loaded and do not cause CO₂ emissions.

It's surprising how low the scroll depth often is. It's lowest when using the navigation to reach another page, which is very often the case. On a conventional website, all contents are loaded, but not on a website with Lazy Loading.

Lazy Loading is standard in all our solutions. If it does not prove to be effective, it can be deactivated. But in most cases, it goes unnoticed. Or it can be specifically used to activate contents when scrolled into the browser.

Databases

Conventional platforms like WordPress, Joomla, or TYPO3 have a fundamental problem. They are database-driven systems, i.e., every page call requires resource-intensive interactions with a database. This consumes additional energy and causes corresponding CO₂ emissions. Modern methods do without databases and generate pages that can be retrieved immediately and with low emissions. How can both methods be sensibly combined?

Plugins and Templates (Themes)

A platform is usually operated with Plugins and Templates (Themes), which allow for the design of a website and the extension of its functionalities. For most platforms, there is a wide selection available. The variety has many advantages, but in terms of web ecology, it has a major disadvantage. The free combination of core, plugins, and templates results in bloated and erroneous code, leading to high CO₂ emissions when accessing pages. With the W3C Validator, errors can be identified and appropriate measures can be taken.

Fonts

Fonts leave a terrible CO₂ footprint. They cause a significantly higher emission than the text they serve. How can the CO₂ emission of a font be reduced?

decarbonise

Sustainable Fonts

Many fonts pollute a page, not just typographically. They leave a terrible CO₂ footprint that can be avoided.

It's not bad advice to assume a CO₂ emission of 0.05g per font or font style. So, for a font family with three styles, you're looking at 0.15g. That costs an entire energy efficiency class. Sometimes even two. Thus, a text page with two fonts, which could easily fall into the first energy efficiency class, promptly drops to the fourth.

Working with the Right Fonts

The file size of fonts can vary significantly, depending on factors such as the font file format, the number of included glyphs (characters), the complexity of the font (e.g., with or without serifs, decorations, etc.), and whether it is a font with or without variable font weights. Generally, file sizes for web fonts range as follows:

WOFF (Web Open Font Format): WOFF is specifically optimised for use on the web and supports compression. The file size for a single WOFF font file can range from about 20 KB to 200 KB, depending on the complexity and scope of the font.
WOFF2: WOFF2 is the newer version of the WOFF format and offers better compression. The file sizes for WOFF2 can be about 30% smaller than WOFF, so about 15 KB to 150 KB for a typical font.
TTF (TrueType Font) and OTF (OpenType Font): These formats are not specifically optimised for the web, but can still be used. Their sizes can vary, often between 50 KB and several MB for fonts with extensive glyph sets (e.g., fonts that support many different languages).

A good practice is to embed only the fonts and font weights that are actually used on the webpage, and if possible, to use WOFF2 formats to reduce data transfer.

Working with Available Fonts

A better practice is to use only fonts that are already installed on the end device. Then, the fonts do not need to be loaded separately and do not cause CO₂ emissions.

The best chances are with Arial, Times New Roman, Courier New, Verdana, Georgia, Helvetica, and Trebuchet MS. Many of these fonts, like Verdana and Georgia, were specifically optimised for screen display, so they are readable in various contexts. The argument that this limits creative work is only partly true. Some designers can create wonderful pages with these fonts. Others manage to ruin pages with the most beautiful fonts.

Energy Efficiency Classes

Energy efficiency classes are a given in all technology sectors, except on the Web. They allow for the assessment of the ecological sustainability of technologies and making climate-friendly decisions. Why are there no energy efficiency classes for web technologies, the fastest-growing technology sector? Wouldn't they be especially important here? How can energy efficiency classes for web technologies be defined and enforced?

decarbonise

Problems of an Energy Label for Web Tools

The footprint of a website consists of many factors. What many do not know: A lot of CO₂-emissions are due to the tools with which websites are created.

When (if at all) talking about CO₂-emissions on the web, attention is mainly focused on the energy demand of server farms and the rapid increase of websites with more and more images, videos, and other resource-intensive contents. The energy consumption of the end devices used to access the websites is also a focus, but not with the same attention.

Data/Data Volume: A website with a lot of data naturally causes more CO₂ emissions upon access than a website with little data. Web tools can't change that. The problem is, modern websites increasingly contain more images, videos, and other resource-intensive contents, which pushes the data transfer further up and with it, the CO₂-emissions.
Data Centres: Data centres consume a large amount of energy to operate and cool their servers. Web tools can do little about this. Many data centres are now reducing CO₂-emissions by using renewable energy sources. But there are far-reaching chain emissions, starting from the manufacture of the hardware to its disposal.
End Devices: The end devices used to access a website also play a role. For example, accessing via a mobile network causes higher CO₂-emissions than access via an energy-saving fibre optic cable. Here too, it's not immediately apparent what these CO₂-emissions have to do with the tools used to create the websites.

All this leads to the conclusion that web tools do not have a significant impact or responsibility when it comes to CO₂-emissions on the web. A fatal misjudgement.

The CO₂-Emission of Web Tools

There are factors directly related to the web tools that significantly influence the other factors, such as the data volume to be transmitted, the energy demand of the data centres, and the energy consumption of the end devices.

Databases: Conventional web tools like WordPress, Squarespace, Joomla, or TYPO3 are database-driven systems, i.e., every page call requires resource-intensive interactions with a database. This consumes additional energy and causes additional CO₂-emissions, which do not occur with database-less systems. These generate pages that can be accessed immediately and with low emissions.
Code Quality: Most web tools are incapable of generating web pages that comply with web standards and can be accessed without errors. They often generate bloated and/or faulty code, which causes a significantly higher CO₂-emission upon each page access than a standards-compliant code that can be processed by browsers without any problems.
Operation and Provisioning: A website can be operated in very different ways, dynamically via a database, statically via files, centralised via servers, decentralised via distributed networks... Each method has its own energy efficiency.

Example: Operating a website via a database as with WordPress requires installing a database, which quickly occupies a storage space of 50MB. In addition, there are often plugins and templates that can amount to several 100MB. It's not uncommon to end up with 1GB per website, continuously consuming energy on the server without a single webpage being accessed. The associated CO₂-emissions do not occur if one opts for a database-less operation, and continuous chain emissions on the server are avoided.

Energy efficiency classes for web tools are certainly a complex issue. But the argument that the footprint of a webpage depends solely on the data volume, server farms, and end devices is tendentious and false. It absolves technology providers and tool developers from their responsibility for developing sustainable products.

decarbonise

Energy Efficiency Classes for Websites

Since December 2023, Website Carbon and Ecograder have been rating the sustainability of websites with energy efficiency classes, focusing primarily on the data volume transmitted during a page access.

Report by Manfred Jurgovsky

In July 2023, I contacted Website Carbon, Ecograder, and GreenFrame with the proposal to explore viable criteria for energy efficiency classes for evaluating web technologies together. The goal was to start a joint initiative to reduce CO₂-emissions on the web. The reactions were friendly but reserved, and cooperation did not materialise.

I attributed the reluctance to the difficulties in defining energy efficiency classes for web technologies. Not all factors can be precisely captured. For example, the exact energy consumption of the end devices used to access websites. Or the manner in which this happens. Thus, accessing via a mobile network causes higher CO₂-emissions than access via an energy-saving fibre optic cable. There are good reasons for scepticism.

I was all the more surprised when Website Carbon and Ecograder started to label their CO₂-analyses with an energy label at the end of the year. After reading the webpage introducing their energy label, I could also better understand the reasons for their reluctance. Website Carbon and Ecograder are interested in an energy label for websites; we are interested in an energy label for web technologies and web tools.

I find an energy label for websites important, but I have a few questions that I would like to raise.

The energy label from Website Carbon and Ecograder is based on the data volume of a website, i.e., the amount of data that is transferred during a page access. Thus, strictly speaking, it does not evaluate the web technology, but its users and their way of handling data. Doesn't this invert the idea of energy efficiency classes? Energy efficiency classes are normally used to evaluate technologies, not the individuals who use them, or what they do with them.
The thresholds of the energy labels are calculated based on the average data transfer, as documented by the HTTP Archive for many years. The average transfer defines the worst efficiency class. That was 2.42MB with a CO₂-emission of 0.85g at the time of the efficiency labels introduction. By February 2024, the average data transfer continued to rise to 2.42MB and the CO₂-emission to 0.88g. Trend increasing.

The problem: As soon as the average transfer increases, all threshold values change, with the strange effect that all websites automatically improve without having to change anything. In the summer of 2023, Website Carbon still communicated an average CO₂-emission of 0.5g, so a webpage of 0.5g would fall into the energy efficiency class F. With the current values from February 2024, it suddenly falls into the energy efficiency class C. What impression do energy efficiency classes leave if they become laxer year by year?
Given the CO₂-emission values achievable with modern methods, the thresholds are far too high. A CO₂-emission of 0.186 for a page view is still ecologically unacceptable. With modern methods, it is possible to significantly reduce data transfer and the associated CO₂-emission. For example, Website Carbon identifies websites created with a minina.media process rarely exceeding an initial emission of 0.02g. This is a reduction of 97.5 percent compared to the average determined 0.8g.

Energy Efficiency Classes for Web Tools

An energy label for websites will strengthen general awareness of the importance of sustainable websites and motivate web developers and designers to optimise their websites. Therefore, such a label is necessary and important.

However, I believe that the providers of the web tools used to create the websites should not be so easily absolved of their responsibility. Therefore, I advocate for the development of an energy label to evaluate the technologies used. It's not about the emissions caused by the data, but about the emissions that are solely the responsibility of the tools. Only in this way can a long-term sustainable improvement be achieved, in my opinion.

One last problem that could be overlooked: Website Carbon and Ecograder use the energy label A+. But this label no longer exists. The labels A+, A++ or A+++ were abolished years ago. Current energy labels are based on a scale from A to G. That wouldn't be too bad. But Website Carbon and Ecograder rightly write on their webpage about efficiency classes that sustainability must be "easy to understand." Outdated energy labels are definitely not that.

But I suggest adjusting the thresholds to really challenge the industry

Our proposal:

less than 0.1g/pv

less than 0.2g/pv

less than 0.3g/pv

less than 0.4g/pv

less than 0.5g/pv

less than 0.6g/pv

more than 0.6g/pv

Web Analytics

Web analytics for capturing user behavior are resource-intensive processes, with corresponding CO ₂ emissions. They are conducted in real-time with complex solutions (Google Analytics, Matomo, or other statistical tools). However, they can also be performed resource-efficiently using the log files provided by every server. In this way, not only are data protection issues avoided, but the CO₂ emissions associated with real-time capturing are also prevented. What solutions exist to evaluate user behavior in a resource-efficient manner?

We combine various methods to effectively reduce the CO₂ emissions of a page view. Website Carbon and Ecograder rarely identify more than an initial emission of 0.02g for websites created using a minina.media process. That's a reduction of 97.5 percent.

The energy efficiency of our solutions is unmatched.

Resource
Check

Welcome

Member Area

Analysis Tools

Page Bloat

Databases

Plugins and Templates (Themes)

Fonts

Energy Efficiency Classes

Web Analytics

Welcome

Member Area

Analysis Tools

decarbonise

CO2 Analysis Tools

Page Bloat

decarbonise

Page Bloat

Omit

Typography

Lazy Loading

Databases

Plugins and Templates (Themes)

Fonts

decarbonise

Sustainable Fonts

Working with the Right Fonts

Working with Available Fonts

Energy Efficiency Classes

decarbonise

Problems of an Energy Label for Web Tools

The CO2-Emission of Web Tools

decarbonise

Energy Efficiency Classes for Websites

Energy Efficiency Classes for Web Tools

decarbonise

Energy Efficiency Classes for Web Tools

Web Analytics

CO₂ Analysis Tools

The CO₂-Emission of Web Tools