Building a fast, sustainable personal website - Part 1

I'll be extremely busy over the next month. With two client projects in the works, plus volunteering to help with another Open Source project, I won't have much time to write up fresh newsletter content.

So for the next two issues I'll share another case study I recently wrote up. This one focuses on my personal website, and how I put performance and sustainability at the heart of its most recent redesign.

This week's issue will be less technical, focusing on some of the design & platform decisions I made. Next issue will be more focused on what I implemented in my code/build process. If you'd rather read everything in one go, then you can find the full case study over on my website.

In May 2021 I decided to give my personal website a fresh lick of paint, and a small technical overhaul. I wanted to achieve a few things from the redesign - to make content easier to access and to really max out the site's performance. I also wanted the site to embody something that I truly care about - sustainability.

I've written about the impact of the internet on our planet previously. To be honest, I wasn't fully aware just how much of a negative impact digital was having on our planet until early in 2020. My moment of enlightenment came when reading Gerry McGovern's book World Wide Waste. Since then, I've sought to continue understanding more about digital sustainability, particularly in relation to the web.

Below are some of the decisions I made during the planning and development of the redesigned website. Each decision either directly impacted on the site's overall performance and sustainability, or set me up to make code implementations that would.


Through this article you will see these two icons next to some of the headings/bullet points.

  • 💚 signifies something that helps with website sustainability
  • 🚀 indicates something that helps with website performance

Jamstack FTW!

My website has used Jamstack architecture for a long time. It is a "static site" if you really want to categorise it. Each page you visit is pre-rendered in a build process before the whole site goes live. This build process runs each time site content is updated and committed to GitHub. Since I'm not frequently updating content, this approach works just fine. I can live with waiting a couple of minutes for a new blog post or code change to go live. This approach doesn't work for every website. It does, however, allow me to implement many website performance and sustainability optimisations directly to the site before it ships. I'll get onto those in the next issue.

Built with Eleventy

Like the previous iteration, I've stuck with Eleventy (11ty) as the static-site generator (SSG) that builds my site. One of the Eleventy features I lean on most heavily to ensure this site is fast and sustainable are Transforms. These allow developers to modify the output of an Eleventy template. I've used transforms for several of the performance and sustainability optimisations I talk about later such as finding and handling critical CSS, applying image placeholders, and creating a simple table of content for blog posts.

Learn Eleventy

If you're interested in learning more about Eleventy then I strongly recommend this (now free!!) course by Andy Bell - Learn Eleventy From Scratch.

This is not a paid ad or affiliate link. I took this course when it first launched and am recommending it from my own experience.

Hosting on Cloudflare Pages

Being a static site, each page of my website is a simple HTML file. This means that I can host it virtually anywhere. However, one of the benefits of a Jamstack approach is integration with a CI/CD (Continuous Integration/Continuous Deployment) pipeline. This allows a new site build to be automatically triggered whenever code or content changes. I could try building that process myself, but several hosting providers offer it out-of-the-box for static sites like mine.

Cloudflare Pages is one of the newest entrants into the Jamstack hosting space. Leveraging Cloudflare's global CDN, it is the first set of key performance and sustainability wins for this site.

  • 💚🚀 Cloudflare's global CDN means reduced latency when serving data to site visitors. It also means data travels a shorter distance to reach the user. This minimises energy usage on the network.
  • 💚🚀 Enabling Brotli compression reduces the size of static assets, further minimising energy usage when serving the site. The smaller sizes also mean downloading the assets takes less time.
  • 💚 Cloudflare neutralises the carbon footprint of its global operations through Renewable Energy Certificates (RECs). While running on 100% renewable energy is the best possible approach, Cloudflare is still taking a step in the right direction here.

🚀 Using

To make navigation around the site even faster I've used the script. Anytime a visitor to the site hovers over a link, intercepts that request and begins preloading the page that is linked. By the time the click (or touch) action is finished, the content for the next page has already started to load (sometimes it may even have finished loading!), making page navigation feel really fast!

About sustainability

Because the script begins to download content for a page before it is viewed, there is the prospect that a user could hover over a lot of links without visiting any. This would result in unused content being downloaded. While that might happen, the other optimisation steps I've taken on the site aim to ensure content downloaded is kept to a minimum.

💚🚀 Using less JavaScript

JavaScript is one of the main reasons for performance issues on websites. I'm not saying that it's bad, but just that it has to be used carefully.

From a performance perspective, poorly implemented JavaScript can result in layout shifts, late loading resources, and can block the main processing thread which can lead to the browser becoming unresponsive to interactions.

From a sustainability perspective, using just the JavaScript I require for each page results in less data being transferred, and less computational power being used by the user's device.

Most pages on my website ship with < 20kB of JavaScript. Some blog pages have lazy-loaded Codepen embeds adding ~50kB more JavaScript on those pages alone.

On my site, I only load JavaScript for the following:

  • Website analytics (I use Fathom Analytics - affiliate link).
  • Measuring the carbon footprint of each pageview (I cover this a bit later on).
  • (see above) requires JavaScript to function.
  • On content pages to provide a share link on supported browsers using the navigator share API.
  • On content pages to render and update the reading progress scrollbar at the top of the window.

💚 Table of content for posts

Making it quicker and easier for visitors to find information is a key part of sustainable website design. Each pageview a website visitor makes while searching for information is extra data and electricity that could otherwise be avoided.

Adding a small table of content for blog posts and case studies on my website is a first step for me in terms of making this site even easier to navigate. I create this table for each page during the site's build process. Using JavaScript, I look at the HTML output of each page, identify all the 2nd level headings (<H2>) and then build out the table of content linking to each section.

This is a small improvement from the previous version of my site, but should hopefully make content easier to find in long-form posts (like this one!).

💚 Tracking site carbon emissions

At the bottom of every page on this website is a Website Carbon measurement. It uses the Website Carbon calculator by Wholegrain Digital to give an estimate of the carbon emissions produced by a given page.

For each pageview, I save the estimated carbon emissions to an Airtable base (affiliate link). This allows me to sum all estimated emissions over the life of the site. I can use this data to analyse and improve the most polluting pages of my site, or even offset the emissions associated with operating the site (which is something I plan on doing).

Currently, Website Carbon Calculator records CO2 generated on page load, not accounting for lazy-loaded images and scripts. I'm planning on building my own calculator that recalculates emissions as a user interacts with a page. This will improve the accuracy of the data in the long run.


WebPageTest on Twitch
The team from WebPageTest have been doing a lot recently. There's a new skin for the app, the blog and guides have been updated, and there's a discount currently running on the API. One other thing they've started is a Twitch channel where they do walkthroughs of website teardowns highlighting some of WebPageTests features.

The next issue of Optimised will be in your inbox on July 23rd. The website has an archive of all previous emails. It's a good place to recap on anything we've covered, and also handy to share with friends or colleagues.

As always if you've got any feedback or specific topics you want to be covered then just reply to this email.

Keep safe, stay well.