A lot of energy is used both when webpages are read in a data centre and when data is transferred to and from the data centre. Choosing a data centre has a great impact on both energy efficiency and speed of the webpage. For this reason it is vital that you think through the points below when choosing a data centre.
Webpages using a CMS, such as WordPress or Drupal, are dynamically generated each time someone visits the page. This is very inefficient because it requires server processing for each view of the webpage, which increases the energy consumption of the web server.
Caching technologies such as Varnish generate static versions of each webpage in advance, so the server load can be significantly reduced for most users. This reduces the energy consumption of the server considerably and makes a big difference to the loading times of the webpages.
Such caching technologies can be complicated to set up, but several web storage operators, such as Kinsta and WP Engine, offer this as an additional service (off the shelf feature). This means that with relatively little effort you can increase both energy efficiency and website performance.
Data centres are rated for energy efficiency with a PUE metric, which stands for Power Usage Efficiency. The PUE rating is calculated by dividing the amount of energy entering the data centre by the amount of energy used to run the computers inside the data centre. This way we see how much energy is "wasted" on activities that have nothing to do with the computer systems (non-computational activities), such as e.g. cooling.
A typical PUE for a data centre is around 1,67, which means that for every 1,67 watts entering the data centre, only 1 watt is used to power the computer systems. High-efficiency data centres, such as those used by Google, can have PUEs as low as 1,11.
Much of the energy consumption when using the internet occurs in connection with data which is transferred over the telecommunications network. The further the information has to travel, the more energy is used on the way.
An example: Let's say you find a cheap web hosting service package from a company in the USA, while most of your users are located in Norway or another country in Europe. Then a lot of energy is wasted moving information across the Atlantic Ocean. In addition, the large distance can contribute to extending the loading time of the webpages.
If you choose a data centre close to the end users, it will be positive for both the user experience and the planet.
Choosing data centres close to the end users is good practice, but what do you do when the users are spread all over the world?
Content delivery networks (CDNs), or nettverk for innholdslevering in a proper Norwegian, are a good solution. With CDN image files are stored on a network of data centres in several locations around the world. With this, in most cases, the largest data files will be loaded from the CDN location which is close to where the user is located. This reduces the distance the data has to travel each time a webpage is loaded – which, in turn, is positive for both energy efficiency and page load time.
Website Carbon Calculator is a recognised and widely used calculator that you can use to check how a webpage affects the planet. The calculator checks the carbon footprint of the webpage you enter, and it shows whether the webpage runs on a green web hosting. Websitecarbon.com also contains information and articles on measures you can take to improve your webpage’s footprint. The Green Web Foundation has a very good overview of data centre providers that claim to use green energy.
How to find a green data centre?
Read more about how to go about choosing a green data centre.
As a developer you have a great influence on the energy efficiency of the webpages you create and maintain. Although some decisions made by designers and content designers are beyond your control, you can optimise the content and designs you receive.
Keep your code clean and simple, avoid duplication and write efficient queries. The code behind the scenes must be a well-oiled machine.
Remember that this applies not only to the code you write, but also to the code you borrow. If you use existing frameworks and libraries, make sure they too are tailored to deliver the functionality you need. Avoid unnecessary plugins that cause bloat - choose plugins that minimise server load and don't put unnecessary weight on the front end.
Point 2 applies much more to JS than to other types of files. Functionality powered by JS is processed on the user's computing device and increases CPU usage, which in turn increases the energy consumption of the device. Do you hear the cooling fans on your laptop whirring? It is energy that is wasted.
Therefore, try to achieve front-end interactions, functionality and animations using more efficient technologies such as CSS. If it fails, you must at least use JS effectively.
The web inspector in Safari has a useful tool for assessing the energy impact of a webpage on the end user's device. The article How web content can affect power usage from Apple's WebKit developers provides some detailed advice.
Images are one of the biggest contributors to the amount of data transferred on most webpages. As a developer you can make various technical decisions that reduce the file size of the images, which automatically also reduces both the energy consumption and the page load time:
As we have already mentioned, one of the solutions is to use a cache server. However, sometimes it is possible to display a static webpage that does not use any database. You do this by writing the webpage as a static file in HTML, CSS and JS, or by using a static page generator or a data centre that specialises in static webpages. They convert the webpage that uses CMS to a static file instead.
Progressive Web App (PWA) technology enables websites to take advantage of functionality normally seen only in native apps.
One of the core features of a PWA is the ability to cache files on the user's device, so that content and ”assets” do not have to be reloaded every time the same user visits a webpage. In this way the amount of data the user transfers is reduced. This applies particularly to mobile devices which use more energy for data transmission than wired connections. In addition, it can help improve loading time and user experience.
"Lazy loading" means delaying the loading or initialisation of resources until they are actually needed. This improves performance and saves system resources.
An example: A webpage has an image at the bottom and the user has to scroll to see it. In many cases the user will click away from the page without scrolling all the way down to the image. The energy and resources are therefore wasted on loading the image without the user having seen it. One solution is therefore to insert a placeholder for the image and only load it if the user scrolls down to it.
Some advantages of lazy loading:
This is how to implement lazy loading:
There are several open source libraries you can use. Here are some examples:
Different methods of implementation:
Lazy loading on imperva.com
Accelerated Mobile Pages (AMP) ensures that content loads faster on mobile devices by removing unnecessary code and file weight. In this way the user gets a minimalistic version of the original webpage.
Google prioritises AMP content in search results on mobile phones and tablets, especially for news-related topics. This can therefore help to increase the visibility of your content.
But note that AMP is a powerful tool that must be used carefully. The disadvantages are that the content is displayed on a Google domain and that some of what is removed by AMP may be important to the user.
You can reduce tracking and advertising code which consume data without providing much value to the user. Find out how to analyse third-party performance.
A third-party external service is a service that communicates with webpages from outside the pages’ own server. Here are some examples many people use every day:
If you, as a developer, use a lot of external services, you have to download all of them and wait for the information from them every time you load a new webpage. The more calls you have, the longer you have to wait. The load on your own server becomes higher and the probability of the page having more problems increases.
In some cases, loading of the webpage will wait until after the data transfer is complete between the webpage and the external service. If the service is called in the header and is then interrupted, the page will refuse to load.
There are actions to make it go faster, such as asynchronous code loading. But in most cases the volume of extra data will be the biggest problem you'll have to deal with when you troubleshoot third-party performance problems.