Sustainable web design

We want our blog to provide much value to our readers. With our origins in open source, we share almost everything that we know. At the same time we want it to be a good experience, so easy to read, quick to load, and not invading any privacy. For that reasons, we made some extreme decisions a while back. No tracking and no cookies are just a few examples. With a changing climate we want to go a few steps further. So while overhauling this blog in 2024, we also focused on being more sustainable and applying eco-friendly measures wherever we can.

Focus on reducing CPU cycles

Every action costs an amount of energy, from development up to you as reader looking at this page. Let’s have a look at some of the following measures that we implemented:

• Static website generator
• Reduce number of systems

Switching from WordPress to Hugo

In the past we used WordPress to manage and present our blog. Now we use Hugo , a static website generator. Instead of running a combination of PHP and a MariaDB instance 24/7, we now only run the generator when changes were made to the blog. This gives a huge reduction in memory usage and CPU cycles required to keep powering the website.

Development systems

Our development systems are also optimized to limit their CPU usage, including running tasks on low-energy devices. Where possible we consolidated systems, unless this was in conflict with security principles that we apply. Some higher risk environments will be separated, but otherwise consolidation is one of the ongoing objectives.

Reducing bandwidth

• System fonts
• Compressing assets
• Increase caching
• Rate-limit bots
• Block outdated or misbehaving systems
• WebP images

Using default system fonts

This blog now uses system fonts only. By using a so-called font stack that only contains fonts that are commonly available, readers will get typically a font that is optimized for reading text. The additional benefit is speed, as no external font has to be downloaded and processed.

Compressing assets

Most file formats can be compressed. The result is much smaller data transfers, at the cost of some CPU cycles to compress and decompress. In the past we let our web server compress almost all files (except images) using Gzip compression. That means that the web server was doing this so called ‘on-the-fly’ compression all day. Even for files that were requested thousands of times a day. Nowadays we pre-compress all files and then offer it when a client supports it. For maximum coverage we now support both Brotli and Gzip. This one-time compress action will be done using the best possible compression options, to save bandwidth as much as possible.

Increase caching possibilities

In the past we had somewhat limited possibilities when it came to caching. So with the 2024 overhaul, we simplified the configuration of our web server yet enhanced caching settings. Based on the content type (MIME types), we provided a hint to clients how long they should cache resources. This way less requests have to be made over the long term.

Rate-limits

With the overhaul we implemented more strict rules when it comes to our bandwidth. Our traffic pool is big, but that doesn’t mean we can be more progressive in reducing it further. Clients (including bots) that misbehave, get rate-limited. The response returned is HTTP 429 with a message indicating that rate-limiting was applied. When the client does not resolve their issue, we go a step further and block it. We already saw a lot of tools waste a lot of resources, including bandwidth, CPU cycles, and energy.

Blocking outdated clients

This website was made with the “open” mindset of the web. Almost any client should be able to connect, as long as it is fairly modern. For that reason, we don’t use the most strict protocol set. This way somewhat older systems can still connect. At the same time, clients that are outdated or simply don’t support basic protocols or technologies, will be blocked. For example, this website will only allow HTTPS connections. Older TLS versions are disabled, as well as older ciphers. Does your client not support at least HTTP 1.1 and content encoding, chances are big that it won’t be allowed. These older clients should be updated, so they support the modern web. The benefit is also that less data is required to retrieve content.

WebP and SVG for images

Before we used mostly files in JPEG or PNG format. With WebP being introduced in 2010 and available for some time now, most modern browsers support it. Screenshots and other images were converted to WebP and are the preferred resource. Only if the browser does not support it yet, we provide a fallback to PNG or JPEG. Icons and our logo are now Scalable Vector Graphics (SVG), which provides a much sharper result and a reduced file size.

More green energy in the mix

With the development of the blog, we also looked at how we can increase the amount of green energy. This is energy from renewable sources, including our own solar panels. That is also why we moved some tasks to during the afternoon, when the most solar energy is available, such as some backup tasks.

Reducing data storage

Every website will quickly grow when it comes to storage on the disk or in a database. Although we no longer use a database engine, the storage is still a thing. For that reason, we simplified our backup strategy, including the usage of snapshots. Now we can go back longer in time, while reducing the overall storage needs. Also, the backup structure has been simplified, as everything is now in one directory together. With WordPress this was a combination including the WordPress software, plugins, templates, images on the disk, and the database export. With a much simpler disk structure, it is easier to replicate data or make a standalone copy. For example, for disaster recovery we still want to have multiple types of backups and in different locations.

Duplicate data reduction

The backups above are the only exception now when it comes to duplicate data. While building up our internal website structure, we removed as much as possible to limit data duplicates. So we don’t have a development, test, and production environment for the website. One system does the development and testing, the output (generated by Hugo) is then synced to production system. Obviously with an optimized method to reduce time, bandwidth, and CPU cycles.

User Experience Design (UX)

We want the best possible experience when browsing our website, so we applied multiple measures to improve the blog and its interface.

• User interface
• Focus on performance
• Reduce errors in HTML and CSS
• Limit JavaScript usage
• Error handling

User interface

When redesigning the blog, we applied the Mobile First approach. Articles should be readable (and fast) on a mobile phone, so all clutter was removed. A simple header, content area, and footer is what remains. On larger screens, the content area will be capped to ensure that the article is still easy to read.

HTML and CSS

Using HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) most of the pages are formatted and styled. This blog uses HTML5 and we tried to minimize errors in the syntax. This way it should show correctly on as many devices as possible.

Limited use of JavaScript

JavaScript allows developers to use powerful events within a website. Our focus is on getting articles clearly on your screen without JavaScript when possible. The only exception is our search engine, that runs on the client system itself. It requires some logic processing that by default HTML does not support. For that single page we tried to find a small library that allows you to search in all articles, without any overhead on our systems.

Performance of the pages

Using the proper HTML and CSS syntax is a good start, but not enough. Keeping it as small as possible decreases the overhead on the client. After all, there is less to process, resulting in pages that load and show quicker. So where we can, we stripped out useless HTML tags and don’t use a CSS framework. Instead, we only add CSS when needed for proper display. When adding new pieces, we look directly on how to consolidate and decrease overhead. In this case there is additional value in it, as all CSS is available in a <style> tag. The browser does not have to do an extra HTTP request, but can directly start processing the page. This helps with speeding up the page rendering. For those readers active in web design, magic words like Above the Fold, First Paint, First Contentful Paint (FCP), and Largest Contentful Paint (LCP). In simplified terms that would mean that the shorter the time it takes to achieve these, the quicker a website loads and shows on your screen.

Error handling

If a page does not exist (404), we point you to the search engine on the website and a link to main page. This way you can easily navigate to a point that works and might help to find you the information that you were looking for.

For search engines we started to respond to outdated pages or assets with HTTP 410 (Gone). This way we want to signal them that they should not retry, and instead focus on pages that do exist.

Questions or suggestions?

Do you have any feedback for our initiative to make this blog more eco-friendly? Let us know!