A sample energy and efficiency assessment by Groundlake.
September 2021
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:
Finally, we end with a summary of potential savings based on the analysis.
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:
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.
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.
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:
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.
A more in-depth review of editing processes could be used to assess the estimated usage patterns given in the report.
Based on the analysis, we recommend some short-term, low-effort actions which can be taken immediately.
Install caching for site content. This can be achieved using existing WordPress plug-ins.
Install automatic image conversion to a modern format, such as WEBP format. This can be achieved using existing WordPress plug-ins.
Install further existing WordPress plug-ins to streamline and optimise page loads and performance.
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.
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.
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.
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.
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.
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.
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.
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:
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:
This section analyses the performance and efficiency of standard editing and publishing activities on the website.
The key usage patterns for administration and editing of the website are:
The editor logs in, navigates to the Wordpress posts page, and writes a new post. This post is previewed, saved, published and viewed.
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) |
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:
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%) |
This page is a standard Wordpress administration dashboard page.
URL used: https://...
Lighthouse methods:
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 |
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:
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 |
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:
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 |
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.
This section analyses the performance and efficiency of the public aspects of the website.
The general use patterns for public access to the site are:
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) |
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:
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) |
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:
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:
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.
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:
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.
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:
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. |
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.
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 |
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.
The website uses the external party Let's Encrypt for establishing SSL connections. See the relevant section under "Suppliers" for more information.
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.
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.)
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.
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.
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 |
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.
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.
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.