At the core of my work, I focus on digital sustainability. But what does this actually mean?
What we’ve come to understand is that Data = Electricity = CO2
So we minimise data transfer from images and video to CSS and JS by using using very clever build tools and minifying everything to reduce the data transfer needed and therefore the amount of electricity and CO2.
But what if there’s more we can do?
One of the key things that this sort of thinking skips out on is the entirety of the backend of the website both the CMS and the server itself.
A quick win would be to switch to green hosting - hosting that uses renewable energy; easy right? But what about squeezing every bit of performance from your server.
Now CMS’ can be big bulky, require a big database and take ages to load - WordPress can be an example of this depending on the size of the database and the complexity of your content although there are ways around it.
When approaching a project its always good to have a toolkit that WordPress can be a part of to ensure that you are using the best tool for the job as well as the tool that is the most sustainable from both aspects (one that is lightweight enough not to use a lot of energy and one that is written well and well supported)
If you don’t need DB access all the time for brochure websites for example - you can cache everything and update it when needed - this way the database will only be interacted with when the cache is cleared in order to rebuild itself. Another thing could potentially to “export” a static copy. This means that the database doesn’t need to be interacted with as the browser would render a static HTML file - static site generators have exploded for this reason, using a “database” and set templates to create a static site which bypasses any database issue.
Obviously this doesn’t work in all cases and sometimes database interactions are always needed especially for more complex data applications. In these circumstances you need to review your application and the database behind it - WordPress can easily be extended to cater for custom database structures meaning that previously complex queries can become straight forward meaning that MySQL (or MariaDB) require less memory and become a lot quicker at running the queries needed to generate the web page and lets face anything more than simple post meta becomes slightly unwieldy.
There are many ways to measure this you can measure the average load which while does naturally increase with high traffic but with a more performant back end it wouldn’t be as much. The other way to be to measure the TTFB which shows that any back end code and database query has run quicker.
This actually has a knock on effect of reducing the power needed to run the website too meaning that you may not need the same amount of resource the website needs which means cheaper hosting so it’s a win win situation.
All the performant database queries in the world won’t be enough if your code itself is extremely bloated - WordPress is a great example of this. All those plugins and extremely large themes that introduce new function and can have really badly written code which slows down your website - I’ve been very vocal about unnecessary plugins and replacing them with your own better written code. The themes I build tend to follow PSR-4 standards (controversially not WP as they are broken IMO) and have a lot of custom function with them so I don’t need to use many plugins usually only two!
Front end size is still important so don’t simply ignore it - each aspect is as important as the others so treat all of them with the respect they deserve and make the biggest impact you can without impacting on our planet.