One of my original reasons for building Tanzawa was I wanted a blogging engine that, while pleasant to use, put a hard focus on efficiency for the express purpose of reducing carbon emissions. This has informed a number of architecture decisions in Tanzawa itself: no big background tasks, no db server, only make optimized images on their first request to save disk / cpu and more.
To bring this in to focus, each page on Tanzawa has a badge that from websitecarbon.com that measures and reports the amount of carbon required to get that page from my server in Germany to you. It's not perfect, but it raises awareness.
I don't run any analytics on my site, so I have no idea how often people click on things on my site, but my buddy mario saw I post I wrote and decided to test his own fusioncast.fm website.
This is the first documented instance I have of people being inspired to reduce the carbon impact of their sites based on my work! One site down, a million left :)
This was my first week using Tanzawa to power my actual blog and not just the dev blog. So far it's been great. I love how easy it is to post. I love that my site is IndieWeb native. I love that my site's stability has improved because I no longer require a database server. And I love that it's using fewer resources. It's great.
While cutting the transfer size in half with a format change is a good start, I still don't need to be serving (at times) 4000px wide images. This is noticeable in streams where posts usually have images ( Checkins etc..) where the text loads instantly, but the progress bar lingers while images load.
Rather, I'm going to change it to serve a resized (max 800px wide? ) image unless the original is specifically requested.
Lastly, I want to start building a list of things that must (not should) be done before I can feel comfortable releasing Tanzawa for others to use and then start working on that list bit-by-bit.
Took my bike to the cafe to work a bit this afternoon. It’s so much fun. I can’t but feel like my parents and peers were sold a lie that driving brings freedom.
We've been using our electric assist "mama-chari" a lot more recently. I've been taking it to a local coffee shop that I'd usually walk (15 minutes) or drive (5 minutes)to and it's been great. My wife has been taking it to her parent's house (5.5km away) where I'd either drive them round trip or we'd take the train. Travel time ends up being about the same regardless of the method of transport we take.
What I like the most about cycling is how you can travel quickly and you're not disconnected from your environment like you are with a car. It feels more human.
How polluted is the air today? Check out the real-time air pollution map, for more than 100 countries.
Love this site that shows me the air quality from around the world. The simple visualization at the bottom with a colored square for each day of the year really lets you easily see trends in air quality over time. Izumi-ku, Yokohama's air quality looks to be improving over the years. Yay!
Being an independent journalist – or an office worker if you wish – I always reasoned that I needed a decent computer and that I need to pay for quality.
This is article about How and why I stopped buying new laptops from Low Tech Magazine about reducing your environmental impact by avoiding the upgrade cycle and using your old (or used) laptop inspires me to continue using mid-2014 Macbook Pro as long as possible.
The author favors older Thinkpads because of their repairability. Repairability gave me a pause when I originally purchased my laptop. Thankfully it hasn’t been a problem yet, but I fear it may take my machine before it’s time.
Sustainability of websites is mostly determined by how much electricity the website consumes. All websites consume electricity 24/7. There's a server powered up, listening for requests. They consume it by proxy transferring bits to the client and they consume it on the visitor's computer by rendering the content.
You can't do much about electricity consumption of a server being online 24/7 beyond simplifying your hosting infrastructure (you don't need a load balancer). What's easier to control is the the number of bits you send to clients who visit your website.
Images are a large source of unnecessary bits. We shouldn't be uploading raw uncompressed 40MB images designed for a poster to display on a smart phone. They'll load slow, chew through our visitor's data plan, and consume unnecessary electricity to transfer and render such a large image. You should resize your images for the web.
Traditionally images are input into a website with a simple image tag like below:
<img src="https://jamesvandyne.com/wp-content/uploads/2020/10/voted.png" alt="Ballot approved" border="0" width="600" >
You tell the browser where the image is, give it some alt text for cases where the image doesn't display / accessibility purposes, and maybe even set a size. Once your browser encounters this tag it will dutifully download and display the image. Life is good.
But what if that image is halfway down the page and completely off screen? Doesn't matter - still downloaded.
It doesn't matter that they may not scroll down far enough to see the image, it's in your markup the browser downloads it. This is a waste of electricity and bandwidth.
By simply adding
loading="lazy"to our image tags the browser will lazy load our images, i.e. it won't download the image until is nearly in view.
So by modifying the example above to
<img src="https://jamesvandyne.com/wp-content/uploads/2020/10/voted.png" alt="Ballot approved" border="0" width="600" loading="lazy">
we can reduce the number of data transfers, reduce total transfer size (unless they scroll the image into view), reduce electricity consumption across the board, and improve page load times. It's a win-win-win.
I started watching Long Way Up this weekend. What a fantastic show and fascinating journey see - from the tip of Argentina up to L.A. on electric motorcycles.
As a fan of electric vehicles the first few episodes are bittersweet as they figure out how the bikes and charging work. Cold weather shortens the lifespan of any battery, so starting the journey at the end of winter and traveling through remote areas without a solid grid increases the challenge to a new level.
Seeing the beauty of these towns makes me want to visit Argentina and Chile so I can see it with my own eyes. The flight from Japan would be brutal as most flights to South America from Japan transit in Houston or L.A. – so a 10 - 14 hour flight to make it halfway.
One of the tasks left for me to improve the sustainability of my website is to reduce the size/transfer of the images on my site. This is actually two tasks: optimize the images themselves, two lazy load images so they only load when scrolled into view.
My blog is powered by Wordpress, so it should be as simple as installing one of the many "image optimizer" plugins. However, for a variety of reasons, including but not limited to image optimizing happens on their servers, or they want to use their CDN to delivery my images, or the plugin just kinda looks spammy, I haven't taken the next time.
I've asked myself how do I address image optimization on my website: do I write my own image optimization plugin? Or do I do something else?
I haven't written PHP in a very long time I don't partially fancy developing a new Wordpress plugin. But it could be nice to make a nice, clean, no fuss plugin available for others to use.
However, I'm leaning towards "something else" and think a more generic solution might be better. i.e. What if I had a small daemon (probably Python, maybe Rust as an excuse to learn it?) to monitor a directory and automatically optimize the images when they're saved. This way no plugin is required and it could be used no matter the blogging engine.
As part of my process of improving the sustainability of the digital things I run, including this blog, I'm moving my servers from Digital Ocean's NYC1 datacenter to their Frankfurt datacenter. The Frankfurt datacenter is co-located at Interxion, and is powered by 100% renewable energy.
Below is a quick overview of the steps required to move your existing droplet to Frankfurt (or London, or Amsterdam) so it can be powered by 100% renewable energy. Including the time to take a snapshot, the process took me about 15 minutes.
For other tips related to improving the sustainability of your sites, read designing sustainable digital products.
1. Update your DNS TTL (Time To Live) Settings
Moving your droplet will mean getting a new ip address. Reducing your DNS' TTL settings prior to moving your droplet will help ensure minimal downtime as DNS servers update their record of your new home. I set mine to 2 minutes.
2. Make a Snapshot of your Server
While Digital Ocean allows you to make Live Snapshots, for anything stateful (like a blog, or application), it's best to shutdown your server before making the snapshot to ensure that no data is missed.
- Select your droplet in admin console.
- Select the power sub-menu and click the Turn off button. This takes a minute or two.
- Once shut down, click the snapshots submenu.
- Click the take snapshot button. This took about 8 minutes to complete the snapshot.
3. Move Your Snapshot to Frankfurt
By default Snapshots are only available in the region in which they were created. In order to start a new droplet in a different region you'll first need to transfer it.
- Select the Images menu in the admin console.
- Find your Snapshot in the list and click the More button.
- Select Add to region and select "FRA1" for Frankfurt. It should only take a minute or two, depending on the size of your droplet.
4. Create a New Droplet
Create a new Droplet. In first step where you select an image, rather than selecting an operating system, click the snapshots tab and select your new snapshot. Other options should match your existing droplet. Select the region "Frankfurt 1" and finally click Create Droplet.
5. Update DNS
Once your server has been provisioned, you'll see the ip address. Update your DNS records to reflect the new ip. With the lowered TTL settings, it should be near instantaneous. My DNS updated before the server was even finished booting.
6. Confirm it's Working and Delete your Old Droplet
Once the server is online and DNS is updated, you should be able to access it just like nothing has changed. After you've confirmed it's working properly, delete your old droplet so you are no longer charged for it.
I've always enjoyed using Digital Oceanand being able to host with them using 100% renewable energy ensures that I'll be a customer for years to come.