Published 31 July, 2019.
As promised previously, I’ve made some changes to this site to reduce it’s carbon footprint.
To recap, I was inspired by a study which identified four kinds of energy use communications technology may be responsible for:
A post discouraging you from a new smartphone, laptop or internet-connected microwave feels like quite a separate thing from addressing the first three of these points, so I’ll focus on those here.
The results each time were about the same: there was a small spike in CPU usage when the page was loaded, but that quickly went down to zero.
Something I’ve been wondering about for a while was whether bright, white web sites use more power than dark-coloured ones. Turns out that this was a rather dated notion in 2007, but may be making a comeback with evolving OLED technology.
As it’s pretty safe to say that there would be very few CRT screens being used to access this web site, the decision of whether to switch to a darker colour scheme should be decided by LCD vs OLED screens. However, I haven’t been able to find any reliable sources on how common OLED screens are, and what the power consumption differences would actually be in practice.
As such, I feel it’s a bit premature to switch to dark mode just yet, though I’ll certainly be keeping an eye on it.
For what it’s worth, this site uses the
prefers-color-scheme: dark CSS media query. If you have an OLED screen and haven’t already, consider enabling dark mode to save a bit of energy.
My spirits were pretty high after seeing how well my site did with consumer device energy use.
Looking into how bloated this site has become brought them crashing down to earth.
The network tab of Safari’s developer tools show how unnecessarily large the front page was:
Grouping these resources, we see some very hefty assets are being downloaded for what is a very simple page:
|Resource type||Size||% of content||% of content + my face|
|HTML content||9.10 KB||100%||9%|
|My face||83.08 KB||913%||90%|
|CSS (Bootstrap, Font Awesome, and Rouge)||223.38 KB||2455%||242%|
|Font Awesome assets||143.76 KB||1580%||156%|
|Google fonts||40.38 KB||444%||43%|
|Raven (error reporting)||13.48 KB||148%||14%|
I decided that the HTML of the page and a picture of my face is the important content of the home page, then I measured the size of everything else in relation to that.
Here are the steps I went through to slim this page down:
The easter egg I’d included in this website (hidden behind the Konami code and probably never actually discovered) was four times as large as the important content of the home page. It had to go.
The combination of Bootstrap and Font Awesome was also far too large for such a simple site. Just by replacing
@import "bootstrap-4.3.1/bootstrap"; with the following (which picks out the parts of Bootstrap I need), I knocked almost 90 kilobytes off the CSS download.
@import "bootstrap-4.3.1/functions"; @import "bootstrap-4.3.1/variables"; @import "bootstrap-4.3.1/mixins"; @import "bootstrap-4.3.1/root"; @import "bootstrap-4.3.1/reboot"; @import "bootstrap-4.3.1/type"; @import "bootstrap-4.3.1/code"; @import "bootstrap-4.3.1/grid"; @import "bootstrap-4.3.1/tables"; @import "bootstrap-4.3.1/utilities"; @import "bootstrap-4.3.1/print";
I switched to using individual SVG files from Font Awesome. This cut down the CSS even further, and reduced the size of Font Awesome assets to 8.55 KB.
The Google fonts I was using weren’t spectacular. Merriweather is very similar to Georgia, and I am just as happy using a collection of widely installed fonts for my headings. So I removed the Google Fonts.
As I’m no longer using any client-side script, Raven is no longer required.
After this, the network tab in Developer Tools was looking much better. But there was one more asset I could look at shrinking—the picture of my face.
I had always served this image from Gravatar, a site which serves user avatars to sites which don’t want to manage user avatars themselves. I was really surprised by how little the avatar they served was optimised for use on the web.
Switching to a version of the image optimised using MozJPEG saved a further 37 KB.
|Resource type||Size||% of content||% of content + my face|
|HTML content||8.02 KB||100%||15%|
|My face||45.42 KB||566%||85%|
|CSS (Bootstrap and Rouge)||74.92 KB||934%||140%|
|Font Awesome icons||8.55 KB||107%||16%|
Over a weekend afternoon, I went from a total page weight of 873.03 KB (947% of 92.18 KB important content) to just 174.92 KB (256% of 53.44 KB of important content).
I’m unable to change the site’s caching behaviour, but thankfully GitHub Pages’ default response headers are pretty much what I’d want. They include a
Cache-Control header which allows assets to be cached for one hour, and an
ETag header which clients can use to figure out whether assets are still valid once that hour is up.
Ideally the Font Awesome icons I’m using would come from a separate CDN which serves those assets to lots of sites with a really long cache time, but I wasn’t able to find a service offering this.
As this is a static web site, it doesn’t require much CPU to keep it running. After each commit to the master branch, GitHub compiles the site and puts it onto it’s CDN network.
There’s not a lot of information about GitHub and their energy use that I was able to find, but there’s not a great deal of energy being used generating, storing, and serving the site.
Before starting this exercise, I ran tests on every change to this site on CircleCI. These tests checked that the site’s configuration was not badly broken, and that the site was spelled correctly.
For this site, constant integration isn’t that important. I run these same tests in a pre-commit hook, GitHub handles misconfiguration gracefully, and spelling mistakes aren’t that big of a deal.
Given this, I’ve switched CircleCI off for this site.
The majority of this work was done over a few hours across two Sundays while enjoying a few beers. I feel like even this small amount of effort has made a big change to amount of energy used by this site.
A nice side effect of this work has been making this site feel super fast.
There’s opportunity to take this even further by switching to a lighter CSS framework (or ditching CSS frameworks all together), but that would involve quite a bit of work.
If you run even a small web presence, I’d recommend that you go through the a similar process.