Energy Appraisal Report: Clientea Examplis

A sample energy and efficiency assessment by Groundlake.

September 2021

Introduction

This report sets out detailed analysis for the energy usage of the Clientea Examplis website.

The report begins with an Executive summary setting out an overview of findings, and a set of short-term and long-term suggestions.

Following on from this, the main report covers:

  1. The aims and scope of the analysis in more detail
  2. The key usage patterns for the system, including technical investigation of the pages involved
  3. The underlying technical services which are used in the operation of the site
  4. Third party suppliers employed to operate the site

Finally, we end with a summary of potential savings based on the analysis.

Executive summary

In general, the technical setup for the Clientea Examplis website is fairly standard. As such, there are several common issues currently making the site less efficient than modern technology allows for, which in turn will have an effect both on energy usage, and on search engine performance.

Fortunately, the standardised nature of the setup also means that immediate solutions are readily available and can be applied with relatively minimal effort.

In particular, the key immediate issues that the website faces are:

  1. Images and other content are not explicitly cofigured to be cached, resulting in browsers reloading entire pages more often, and much slower and heavier page loads over time. This increases energy used by the hosting server, clients, and the infrastructure used to transfer data. This also leads to less favourable search engine ranking, and sees users facing longer load times, especially when accessing the site via mobile data connections.

  2. While some content is minimised by default, many images and content assets are still relatively large by modern standards, and could be automatically reduced, and converted to take advantage of modern formats.

  3. Reliance on heavy social media scripts, in particular the Facebook integration being used. These can occupy up to half of the content transferred currently, and serve to increase the content loaded when accessing the site via a mobile rather than a desktop browser.

In addition, there are key barriers to carrying out more accurate analysis. In particular:

  1. A lack of more in-depth statistics for site access means that analysis has to be based on a 'best guess' estimate. Modelling usage based on type of browser client and pages used can be signficantly more accurate given access to these statistics, as can a review of geographic needs.

  2. A more in-depth review of editing processes could be used to assess the estimated usage patterns given in the report.

Short-term recommendations

Based on the analysis, we recommend some short-term, low-effort actions which can be taken immediately.

  1. Install caching for site content. This can be achieved using existing WordPress plug-ins.

  2. Install automatic image conversion to a modern format, such as WEBP format. This can be achieved using existing WordPress plug-ins.

  3. Install further existing WordPress plug-ins to streamline and optimise page loads and performance.

  4. Set up and install a carbon calculator to automatically track page usage and recommend - or purchase - carbon offsets. This can be achieved using existing WordPress plug-ins and third party services.

  5. Set up and install site usage analytics to track viewers and use of each page, to enable more accurate analysis in future. This may also include extending analysis to international traffic, to determine if measures aimed outside the UK would be beneficial.

  6. Consider replacing Facebook integration with an alternative implementation. This would require some work to a) identify the business need for the current approach, and b) identify potential alternatives that fit with these needs.

As noted above, the site uses a standard WordPress set-up, and most of the above suggestions can be applied in a small amount of time.

Note that some of these suggestions may involve changes to data usage, or may entail payment set-up. We strongly recommend discussing each issue in more depth before implementation to ensure each aligns with the organisation's strategic needs, and legal duties.

There are significant potential savings to be made in the short term, possibly around 18kg of CO2-equivalent emissions on an annual basis, or 73% of current emissions.

Long-term recommendations

In addition to the immediate actions proposed above, we raise here some suggestions and ideas for further discussion and consideration, should Writing Our Legacy wish to integrate efficiency and sustainability more fully into their long term plans and strategy.

  1. Consider identifying a sustainability policy or guidance note, which brings out the organisation's values and principles concerning efficiency and sustainability. This can then be applied to working practices to review the organisation's approach, as well as serve as support and induction material for people joining, or partnering with the organisation.

  2. Establish regular review points of key metrics to keep a more continuous oversight of energy usage and efficiency of the website (and/or any other activities of interest), in order to feed into organisational decisions and strategic aims.

  3. Broaden the scope of analysis to areas of the organisation's activities other than the main website. This could be approached in a modular fashion, looking at different aspects such as the impact of products being created, and events being run, through to administrative activities such as emails and internal communication.


Aims

This report details the findings of technical analysis of the Clientea Examplis website. The analysis concentrates on the energy efficiency of the site, and considers the impact that it has from a broad set of perspectives, including its content and design, usage patterns, and how the site is hosted.

The report will go into technical detail in order to fully assess this, and will draw out specific and general suggestions to improve the performance and efficiency of the system as a whole.

This report covers a single technical aspect of Clientea Examplis's overall activities. We analyse the Clientea Examplis website, which acts as the main site for the organisation. It is a central point where a variety of content can be provided, including:

  • News and updates
  • Information about online and real-world events
  • Useful content and resources for target groups and communities
  • Digital and physical products for sale

As such, the website is aimed at a wide variety of audiences, depending on the business needs and activities of the organisation on an ongoing basis. Visitors may access the website from a wide set of sources, including networking events, social media, marketing campaigns and word of mouth.

The main focus of this report is on reviewing the home page and news pages, and the editing process which backs them. While other pages are an important part of Clientea Examplis's activities, the initial report should raise initially relevant themes which should also affect these other pages. We recommend that further, future reviews take into account the site as a whole, following on from the short term recommendations made here.

This report does not cover the following:

  • Non-news pages, as noted above.
  • Administration functionality outside of posting news, pages, and products. For example, user admininstration and comment editing are not analysed here.
  • How diverse posts and pages are - this report takes a sample post and page as typical, representative content.
  • Use of a mobile app to interact with the site via API.
  • Use of other technology within the organisation, such as use of email, document services, etc.
  • Carbon embodied as part of the process of creating hardware
  • Use of energy to dispose of any hardware

Usage flows

Website administration

This section analyses the performance and efficiency of standard editing and publishing activities on the website.

Usage patterns

The key usage patterns for administration and editing of the website are:

  1. The editor logs in, navigates to the Wordpress posts page, and writes a new post. This post is previewed, saved, published and viewed.

  2. A shop editor logs in, navigates to the Products page, and creates a new product. This product page is previewed, saved, published and viewed.

Between September 1st 2020 and August 31st 2021, 15 posts were created and published, and 12 pages were published or modified.

For this assessment, we assume that publishing a post or a page is roughly equivalent to modifying it, and that a post and a page are roughly equivalent in terms of process taken and energy used. This gives us a minimum estimated number of edits of 27.

In the same time period, 5 products were created and published.

Given time restrictions involved in analysis, we focus here on publication of news pages, rather than of products. Further analysis of the shopping and products section of the site would be fairly simple to carry out in a similar fashion.

From this, we suggest that the following access points be assessed, according to audience:

Point of access Accessor Scale (times per year)
Login page Editor 32 (estimated from 27 + 5)
Admin dashboard Editor 32 (estimated from 27 + 5)
Post/page overview Editor 27 (estimated)
New post/page Editor 27 (estimated from yearly data)
Post/page Editor 54 (estimated from yearly data)

Login page

This page is a standard Wordpress page with no embellishments or additions. It is therefore light on images and third party assets, but requires loading of a large script to check passwords.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 81 53
Total page size (kb) 584 584

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 0.2%, 1.1 0.2%, 1.1
Scripts 90.4%, 528 90.4%, 528
Styles 8.4%, 48.9 8.4%, 48.9
Fonts 0.0%, 0 0.0%, 0
Document 0.7%, 3.8 0.7%, 3.8
Third party 0.0%, 0 0.0%, 0

The bulk of the 528kb associated with script content is the password strength estimation script located at https://.../zxcvbn.min.js (430.6kb out of 528kb, or 81%). This script is an integrated part of Wordpress' login page, but there may be options to replace this or reduce it. NB Upgrading Wordpress would provide a small size improvement of 38k.

Suggestions:

Action Effect / Potential saving
Enable caching for static assets ~540k (~92%) on subsequent page loads
Upgrade Wordpress 38k (6.5%)

Admin dashboard

This page is a standard Wordpress administration dashboard page.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 79 42
Total page size (kb) 868 868

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 14%, 122 14%, 122
Scripts 59%, 512 59%, 512
Styles 20%, 175 20%, 175
Fonts 0%, 0 0%, 0
Document 7%, 57 7%, 57
Third party 0%, 2 0%, 1

Script size is split fairly evenly across multiple scripts, largely between 20k and 128k (15% of total page size). The two largest assets are Wordpress's load-styles.php and load-scripts.php. Script code is largely minified.

As this is a complex page, savings are most likely to come from implementing caching for assets (as per elsewhere on the site), and by reducing the complexity of the dashboard page.

Suggestion Effect / Potential saving
Enable caching for static assets ~800kb (~90%) on subsequent page loads
Dismiss and disable unneeded dashboard elements Depends on user needs

Post and page overview

These two pages act largely in the same way, presenting the editor with a list of news posts or site pages in the same format. This is confirmed by comparing the sizes of the two pages: 591kb and 586kb for post and page overviews respectively. We use the more commonly accessed page for seeing posts in this report.

URL used: https://...p

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 88 34
Total page size (kb) 591 591

Content by type is listed below:

Content Desktop (%, kb) Mobile (%, kb)
Images 3%, 20 3%, 20
Scripts 60%, 352 60%, 352
Styles 27%, 161 27%, 161
Fonts 0%, 0 0%, 0
Document 9%, 55 9%, 55
Third party 0%, 1 0%, 1

As with the site Dashboard, scripts and styles inherent to WordPress's administrative interface make up the majority of content transferred, consisting largely of the load-styles.php and load-scripts.php scripts again.

As such, optimisations to this page are similar to those for the Dashboard, including enabling caching for assets.

Suggestions:

Action Effect / Potential saving
Enable caching for static assets ~530kb (~90%) on subsequent page loads

New post / page

This editing page is used to create a new post or page on the Wordpress site. Separate pages are used to create a post or a page, but the same underlying Wordpress page is used. This is confirmed by comparing file sizes for the two pages (965kb vs 967kb). As such, this report analyses the page to create new posts, and uses this for both types.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 61 25
Total page size (kb) 967 964

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 4%, 35 4%, 35
Scripts 67%, 651 67%, 647
Styles 23%, 223 23%, 223
Fonts 0%, 0 0%, 0
Document 6%, 56 6%, 56
Third party 0%, 2 0%, 3

As with other administration and editing pages in Wordpress, this page mostly consists of scripts and stylesheets in order to present the editing functionality to the user. The script for the WYSIWYG editor (https://.../tinymce.min.js) was the largest script (142kb, or 15% of total page size).

As the WYSIWYG editing functionality is likely to be essential to editors, this may be a necessary size to download. It may be worth exploring opportunities for other, more lightweight editors, but we would suggest this is low priority given the importance of editing content on the site.

Otherwise, this page will benefit from the same optimisations suggested for other pages and the site as a whole.

Suggestions:

Action Effect / Potential saving
Enable caching for static assets ~900kb (~93%) on subsequent page loads

Post preview and confirmation

Here we assume that the size and efficiency for accessing a post or a page is effectively the same, whether the viewer is an admin or general viewer, and whether the page is being previewed or viewed live.

This is confirmed using a simple size check for each page:

Page Size (kb)
Post preview as editor 1,445
Post page as editor 1,466
Post page as reader 1,360

(Generated using Lighthouse in desktop emulation mode, with the URLs https://... for a post, and https://... for a site page.)

See the section on post pages for readers for more detail.

Public access

This section analyses the performance and efficiency of the public aspects of the website.

Usage patterns

The general use patterns for public access to the site are:

  1. Readers view the page, via social media, etc.
  2. In addition, readers may navigate to other posts and the site home page.

Note: The organisation's e-commerce shopfront and other supporting pages make up a significant part of the site's content. For a comprehensive analysis, these would ideally be taken into consideration alongside news pages. However, following initial investigation, we propose that resolving the issues affecting the pages below would also be of benefit to other pages at the same time. As such, these other pages have been omitted from this report, but could be included in a further study for greater accuracy.

Analytics for page access are not available. Below, we use draft estimates based on expected viewing figures.

We suggest that the following access points be assessed, according to audience:

Point of access Accessor Scale (times per year)
Site home page Reader 5,000 (estimated)
Published post page Reader 6,000 (estimated)
News page Reader 4,000 (estimated)

Site homepage

The site's homepage relies on a fairly large number of images, and scripts (both the organinsation's and third party). There is good scope to improve delivery of these and make them more efficient by automatically converting larger images to more modern formats, and to compress assets being delivered. Additionally, the site does not allow browsers to cache most images, resulting in multiple delivery of many assets on rrepeated page loads.

Addressing these issues should be extremely feasible given the existence of Wordpress plug-ins, and changes should drastically improve the efficiency of the site as a whole, beyond the homepage.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 74 28
Total page size (kb) 2,688 2,621

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 60%, 1,612 43%, 1,137
Scripts 23%, 630 40%, 1,058
Styles 7%, 177 7%, 174
Fonts 8%, 207 7%, 175
Document 1%, 32 2%, 45
Third party 22%, 580 41%, 1,077

Carbon equivalence

websitecarbon.com calculates the carbon footprint of this page as 1.41g for each visit, dirtier than 65% of webpages tested.

Suggestions:

Action Effect / Potential saving
Consider whether Facebook integration is required 578kb (42% desktop), 1007kb (56% mobile)
Consider whether an alternative Facebook script is usable Depends on alternative
Look into whether woocommerce files can be avoided for non-commerce pages ~280kb (20% desktop, 16% mobile)
Look into whether theme styles can be minimised, removed, or updated ~100kb (7% desktop, 6% mobile)
Enable caching for assets ~430kb (31% desktop), ~600kb (34% mobile) on subsequent page loads
Serve images in next-gen formats ~70kb (5% desktop, 4% mobile)
Lazy-load images ~500kb (19% desktop and mobile)

Public post

This section analyses performance and efficiency when a general viewer accesses a news post or a page on the site.

Here, we also assume that site behaviour is effectively the same for logged-in administrators and viewers, and so the analysis here is also used in the section for site administrators.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 77 52
Total page size (kb) 1,368 1,787

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 23%, 314 23%, 404
Scripts 47%, 640 55%, 978
Styles 13%, 176 9%, 168
Fonts 13%, 171 9%, 160
Document 2%, 34 3%, 45
Third party 42%, 578 56%, 1007

While there are some sizeable scripts and fonts on this page, we can see that a large percentage comes from Facebook integration scripts: 42% on desktop, rising to 56% (and almost twice as much script content) when accessed via mobile.

The external nature of third party scripts makes it harder to apply changes to these. However, these Facebook scripts already have a caching enabled (set to 14 days), which mitigates the size of their download. This highlights a difference between new visitors to the site, and repeat visitors, which would be more easily analysed with relevant web analytics in place.

There are potential further savings by ensuring that images are served in next-gen formats rather than in JPG format, and by determining if unused scripts and styles are required, and/or removable for the page in question. For example:

  • woocommerce's style.css is downloaded but not used on this page
  • the square theme's animate.css is downloaded but not used
  • the square theme's font-awesome.css is downloaded but only 1.1% of it is used

Potential savings on this page therefore depend on business needs and possible alternative solutions (ie to find a more efficient way to do the same thing).

Suggestion Effect / Potential saving
Consider whether Facebook integration is required 578kb (42% desktop), 1007kb (56% mobile)
Consider whether an alternative Facebook script is usable Depends on alternative
Look into whether woocommerce files can be avoided for non-commerce pages ~280kb (20% desktop, 16% mobile)
Look into whether theme styles can be minimised, removed, or updated ~100kb (7% desktop, 6% mobile)
Enable caching for assets ~430kb (31% desktop), ~600kb (34% mobile) on subsequent page loads
Serve images in next-gen formats ~70kb (5% desktop, 4% mobile)

Carbon equivalence

websitecarbon.com calculates the carbon footprint of this page as 0.91g for each visit, cleaner than 51% of webpages tested.

News page

This page displays a summary of the latest news and blog posts on the site, and therefore brings together a variety of content and images from each post.

URL used: https://...

Lighthouse methods:

  • In-browser generated, desktop mode
  • In-browser generated, mobile emulation

Key Lighthouse metrics:

Desktop Mobile
Performance score (/100) 70 45
Total page size (kb) 2,342 2,699

Content by type is listed below.

Content Desktop (%, kb) Mobile (%, kb)
Images 48%, 1,133 43%, 1,164
Scripts 30%, 706 38%, 1,028
Styles 7%, 165 7%, 176
Fonts 11%, 260 9%, 237
Document 2%, 42 2%, 54
Third party 30%, 696 39%, 1,052

This page contains a similar breakdown to the individual news page, except that there is a heavier reliance of images here, given that multiple posts (and their featured images) are collated together.

As with other pages, we also see a large percentage of content - mostly scripts - being loaded from third parties, and a general increase in page size when loading the content via mobile rather than desktop.

The largest potential savings are therefore in these areas. As per other pages, optimising images and considering alternatives to the third party integration offer the most potential savings.

Suggestions:

Action Effect / Potential saving
Consider whether Facebook integration is required 696kb (30% desktop), 1052kb (39% mobile)
Consider whether an alternative Facebook script is usable Depends on alternative
Enable caching for assets ~1500kb (65% desktop), ~1500kb (56% mobile) on subsequent page loads
Serve images in next-gen formats ~664kb (28% desktop, 25% mobile)

Carbon equivalence

websitecarbon.com calculates the carbon footprint of this page as 1.10g for each visit, dirtier than 56% of webpages tested.


Services

WordPress

At time of writing, the WordPress instance on the site is running version x.x.x.

While not directly relevant to efficiency, we note that there is scope to update the core of WordPress, and many of the plug-ins and themes installed, to more up-to-date versions. We would, however, suggest that this can be set up to be updated automatically for minor updates, and a business decision can be made on whether to update major functionality automatically (with some risk to the site), or to apply this manually at regular intervals.

WordPress efficiency is largely covered by other areas of this report, namely:

  • A caching policy is not configured
  • Images are not as efficient as they could be

We do not therefore repeat these suggestions here. However, in addition to these, the site would benefit on the whole from the installation of a WordPress optimisation plug-in, which would apply in-line resources and lazy-loading of content as applicable.

Suggestions:

Action Effect / Potential saving
Install general purpose WordPress optimisation plug-in Unknown. Would also impact favourably on SEO performance.
Remove unneeded themes and plug-ins Minor site speed-up, less upgrade overhead, and more robust security.
Automatically update WordPress, themes, and plug-ins More robust security, potential savings depending on updated code.

Custom code

The website uses a custom WordPress theme which extends an exsiting, installed theme. The custom code added by the theme in use is standard PHP, WordPress and front-end based, and we do not suggest any changes here.

A review of custom code may be more appropriate in the case of a more fundamental site re-design, if this were to happen in the longer term.

PHP

At time of writing, the web host runs PHP version 7.4.21. While PHP 8 is available and would offer some performance improvements as seen here, 7.4 is suitable for current short-term needs. However, it would be worth considering longer term plans to migrate the site to the later version of PHP.

We were unable to assess internal PHP options for efficiency without making changes to the server. This could be considered for a more comprehensive report.

Suggestions:

Suggested action Potential savings
Confirm whether opcache is enabled Unknown
Consider upgrading PHP from 7.4 to 8.0 Unknown

Apache

The website runs using Apache, although we are unable to ascertain which version without further direct access to the host setup.

Content is served using HTTP/2 where possible, and gzip compression is enabled for non-image assets. Compression and performance of image assets is considered elsewhere.

Connection security

The website uses the external party Let's Encrypt for establishing SSL connections. See the relevant section under "Suppliers" for more information.

Operating system

The hosted site runs a form of Linux, using a fairly standard LAMP stack (Linux, Apache, MySQL, PHP).

As this hosting is based at a third party hoster, options to improve efficiency depend on the packages available from the company, or the willingness to migrate the site to an alternative provider.

Currently there is little reason to switch to an alternative operating system.


Suppliers

Web Hosting X

The site is hosted with UK-based company Web Hosting X. This company works largely with reforestation and offsetting partners to balance out the carbon usage of the company, and of clients. (Read more here.)

(PUE rating currently being checked.)

Let's Encrypt

The website employs the third party Let's Encrypt service to set up secure communication between the site and its users.

Let's Encrypt is a free-to-use service providing certificates for HTTPS connections, which requires a renewal at regular intervals. This process is usually so regular as to be automated, and we note here that this is handled by the "Really Simple SSL" plug-in in WordPress. We therefore propose that no further action is needed currently.


Summary of potential savings

The summary of potential savings is based on changes which can be estimated with some degree of accuracy. Where changes are made to more fundamental aspects of the system (such as hosting providers), potential savings are harder to estimate accurately, and therefore are omitted below.

Data

Access point Client Page size (desktop) Potential saving Yearly multiplier Yearly total
Login page Editor 584kb 540kb 32 17.3 MB
Admin dashboard Editor 868kb 800kb+ 32 25.6 MB
Post/page overview Editor 591kb 530kb 27 14.3 MB
New post/page Editor 967kb 900kb 27 24.3 MB
Post/page Editor 1,368kb 1,028kb 27 27.1 MB
Site home page Reader 2,688kb 1,528kb 5,000 7.3 GB
Published post page Reader 1,368kb 1,028kb 6,000 5.9 GB
News page Reader 2,342kb 2,196kb 4,000 8.4 GB
Total - 29.7 GB - - 21.7 GB

Carbon usage

This section shows CO2e values for public content only. However, where this content is also accessed by editors, viewing multipliers are included.

Access point CO2e per visit (g) Yearly multiplier Yearly total (g)
Site home page 1.41 5,000 7,050
Published post page 0.91 6,027 5,460
News page 1.10 4,000 4,400
Total - - 24.71 kg

In terms of carbon offset by trees, this is equivalent to around 2.5 trees per year.

If potential data savings are applied linearly to this, then there is an estimated scope to save around 18 kg of CO2e emissions per year, for the system being reviewed.


Acknowledgments and references

In writing this report, we have drawn on the following sites, tools and technologies.

Powered by Lighthouse (v 8.1.0).

websitecarbon.com: The website carbon calculator.


About Groundlake

Groundlake is a single-person consultancy aiming to mak computers and technology more sustainable. Focuses include efficiency and energy reviews for single sites, all the way up to long term strategic thinking and planning for aligning technology with future generations.

More information can be found at groundlake.org.

To get in touch, email Graham Lally at graham@groundlake.org.