Creating a new look, even lower-carbon website
by Nick Lewis – Founder of the-sustainable.dev, lowwwcarbon and senior developer at Leap
Asked if I could explain how I managed to drop the homepage down from 169.23KBs to 21.63KBs by a number of people, it felt like a blog post on the topic would be a good idea.
The new look
First, a quick piece on the new look. In part, it was in an effort to reduce the page weight by removing the custom fonts. It was also a chance to modernise the look a little. While I don’t think websites should refresh their look entirely every few years, it felt like a good decision for this site IF I could make a decent reduction in the weight of the pages. It was also a good chance to look at the colour choices and overall font styling, as well as to offer a better user experience in redesigning the navigation.
If I didn’t feel like I could have made some significant improvements then I would not have updated the styling. I think websites should be designed to last, with the aim of sticking with a design for 5 years or more. For this site, it has been only about two years. So I am hoping with this update, I will make it last a lot longer than that.
Website weight reduction and how it was achieved
I often oversimplify this part of website creation when describing it to others. But the truth really is that I spend a long time thinking about what can be taken out, removing what isn’t necessary. Then, I go over the process again.
Test, reduce, review. Then repeat.
CSS and JavaScript
The other truth is that I started from scratch on CSS and JavaScript. The new version was based on one of my starter themes for WordPress, the one I also used to create lowwwcarbon.com. It is built to have the least amount of CSS overhead possible. A very small amount of reset styles, letting the browser handle as much as it can. I then only style what is on the page. By that I mean I don’t use any CSS toolkits like Tailwind or Tachyons. I style what is on the page, nothing more. If I know something can be reused, such as a common grid layout, I create a reusable class or set of HTML structures that can be reused.
I knew from the beginning that I wanted to have a light and dark colour scheme. So I set up a number of CSS variables that could be changed on the colour scheme and preference change.
As for JavaScript, it only has enough vanilla JS by default to run a mobile menu toggle. Plus one file loaded for the privacy-first analytics tool Cabin. To this site, I added only JS for the colour scheme toggle and storing of the preference and a snippet that automatically closes all HTML details tags after opening a specific one. You can read how to do that on my personal website’s blog.
Images
Basic one here. The site doesn’t really include any images. The ‘logo’ is just text, not even an SVG. But that is because I can for this site. About the only image is of my own face on the about page. That image is responsive in sizing, optimised for web as a JPEG, and then converted on the server to WEBP for an even smaller image.
Testing and time
Continuing the truthful notes. This site didn’t come together overnight. Despite the unplanned launch. It has taken many months to create. This is mostly due to only having small pockets of time after work or on weekends to work on it. So, whilst building, I was also testing. I had plenty of time to think in between code writing sessions. This gave me the head space to change things over time. To test, reduce and review. This isn’t always possible with client projects and the deadlines they require.
Final optimisations
I already mentioned in this post that I spent time reducing the CSS that wasn’t needed. In the days before I launched, I spent some time going through the site and editing my CSS even further. Removing code relating to selectors that I know weren’t being used on the page. These were tiny amends. A few characters here, a few there. Maybe a line or two in the CSS file. But every little helps. Now, I could have used purge CSS to do this, but in my experience of it to date, it can often be overly aggressive, or just unreliable. Either removing more than it should or not enough. So, I took the manual approach.
Caching
This almost goes without saying. But it also needs to be said! I certainly try to cache all that I can. I also attempt to increase the cache timings for the files where it makes the most sense. I manually control version numbers on my CSS and JS files in the theme. As this is WordPress, with a live database, I also cache calls from it. So not just static files but database calls too. This really helps to speed up heavy database-led pages like the directory. As the directory needs to update when someone new joins, there are controls that check for new users signing up which then purge the cache of the directory page. This then automatically re-caches. I use the excellent WPRocket plugin to help with the caching of everything.
Concluding
I hope this gives some insight into what went into this new version of the site. I’m sure I could continue, but if I did the post would be too long to be readable.
If this has been interesting, please take a look at the other resources. Please continue helping others, and keep pushing for a lower-carbon web.