Earlier this year we've been asked to help redesign the website of <lowtechmagazine.com>, the primary goal was to radically reduce the energy use associated with accesing their content and to stay true to the idea of low-tech.
This means using technology and techniques of the past, combined with the knowledge of today. Not in order to be able to 'do more with the same' but rather 'to do the same with less'.
In this particular case it means that all the optimizations and increases in material efficiency do not go towards making a website which is faster at delivering more megabytes, but rather a website which uses all the advances combined with specific hardware and software choices to radically and drastically cut resource usage.
Concretely this meant making a website and server which could be hosted from the author's off-grid solar system. <https://solar.lowtechmagazine.com/about/> gives more insights into the motivations on making a self-hosted solar-powered server, this companion article on <homebrewserver.club> will show you how to set up the server.
The main change in the webdesign was to move from a dynamic website based typepad to a static site generated by pelican. Static sites load faster and require less processing than dynamic websites because the pages are pre-generated and read off the disk, rather than being generated on every visit.
Image from the blog showing 19th century telephone switchboard operators, 159.5KB
One of the main challenges was to reduce the overal size of the website. Particularly to try and reduce the size of each page to something less than 1 Mega Byte. Since a large part of both the appeal and the weight of the magazine comes from the fact it is richly illustrated, this presented us with a particular challenge.
In order to reduce the size of the images, without diminishing their role in the design and the blog itself, we reverted to a technique called dithering:
The same image but dithered with a 3 color palette, 36.5KB
This is a technique 'to create the illusion of "color depth" in images with a limited color palette'[^illusion]. It based on the print reporoduction technique called [halftoning](https://en.wikipedia.org/wiki/Halftone). Dithering, or digital half-toning[^digitalhalftone], was widely used in videogames and pixel art at a time when a limited amount of video memory constrained the available colors. In essence dithering relies on optical illusions to simulate more colors. These optical illusions are broken however by the distinct and visible patterns that the dithering algorithms generate.
As a consequence most of the effort and literature on dithering is around limiting the 'banding' or visual artifacts by employing increasingly complex dithering algorithms[^dithering]. Our design instead celebrates the visible patterns introduced by the technique. Coincidentally, the 'Bayesian Ordered Dithering' algorithm that we use not only introduces these distinct visible patterns but it is also quite a simple and fast algorithm.
Dithered with an eleven tone palette, 110KB
To automatically dither the images on the blog we wrote [a plugin for pelican](https://github.com/lowtechmag/ltm-src/tree/master/pelican-plugins/dither) to do it for us. This reduced the total weight of the 623 images on the blog by 89% from 194.2MB to a mere 21.3MB.
### Off-line archive
TODO
** Dither plugin
** Off-line archive plugin
* LetsEncrypt Certificates
* nginx webserver
compression
static file caching policy
http2
ssl
* Materialserver scripts
## Configuring the webserver
As a webserver we use [NGINX](https://www.nginx.com/) to serve our static files. However we made a few non-standard choices to further reduce the energy consumption and page loading times on (recurrent) visits.
To test some of the assumptions we've done some measurements using a few different articles. We've used the following pages:
`CW` = [How To Downsize A Transport Network: Chinese Wheelbarrows](https://solar.lowtechmagazine.com/2011/12/the-chinese-wheelbarrow/), 996.8KB, 23 images
We run gzip compression on all our text-based content, this lowers the size of transmitted information at the cost of a slight increase in required processing. By now this is common practice in most web servers but we enable it explicitly. Reducing the amount of data transferred will also reduce the total environmental footprint.
Caching is a technique in which some of the site's resources, such as style sheets and images, are provided with additional headers thta tell the visitor's browser to save a local copy of those files. This ensures that the next time that visitor loads the same page, the files are loaded from the local cache rather than being transmitted over the network again. This not only reduces the time to load the entire page, but also lowers resource usage both on the network and on our server.
The common practice is to cache everything except the HTML, so that when the user loads the web page again the HTML will notify the browser of all the changes. However since <lowtechmagezine.com> publishes only 12 articles per year, we decided to also cache HTML. The cache is set for 7 days, meaning it is only after a week that the user's browser will automatically check for new content. Only for the front page this is disabled.
The first time a page is loaded (FL) it around one second to fully load the page. The second time, however, the file is loaded from the cache and the load time reduced by 40% on average. Since load time are based on the time it takes to load resources over the network and the time it takes for the browser to render all the styling, caching can really decrease load times.
Another optimization is the use of [HTTP2](https://http2.github.io/) over HTTP/1.1. HTTP2 is a relatively recent protocol that increases the transport speed of the data. The speed increas is the result of HTTP@ compressing the data headers and multiplexing multiple requests into a single TCP connection. To summarize it has less data overhead and needs to opens less connections.
The effect of this is most notable when the browser needs to do a lot of different requests, since these can all be fit into a single connection. In our case that concretely means that articles with more images will load slightly faster over HTTP2 than over HTTP/1.1.
Even though the website has no dynamic functionality like login forms, we have also implemented SSL to provide Transport Layer Security. We do this mostly to improve page rankings in search engines.
There is something to be said to support both HTTP and HTTPS versions of the website but in our case that would mean more redirects or maintaining two versions
For this reason we redirect all our traffic to HTTPS via the following server directive:
:::console
server {
listen 80;
server_name solar.lowtechmagazine.com;
location / {
return 301 https://$server_name$request_uri;
}
}
Then we've set up SSL with the following tweaks:
:::console
# Improve HTTPS performance with session resumption
SSL sessions only expire after three hours meaning that while someone browses the website, they don't need to renegotiate a new SSL session all the time:
We enable OCSP stapling which is quick way in which browsers can check whether the certificate is still active without incurring more round trips to the Certificate Issuer. Most tutorials recommend setting Google's `8.8.8.8` and `8.8.4.4` DNS servers but we don't want to use those. Instead we chose some servers provided through <https://www.opennic.org> that are close to our location:
Last but not least, we set change the size of the SSL buffer to increase to so-called 'Time To First Byte'[^TTFB] which essentially shortens the time between a click and things changing on the screen:
This will prompt an interactive screen where you set the (sub)domain(s) you're requesting certificates for. In our case that was `solar.lowtechmagazine.com`.
Then the only thing you need to do in your NGINX config is to specify where your certificates are located. This is usually in `/etc/letsencrypt/live/domain.name/`. In our case it is the following:
One of the page's design elements is to stress the materiality of a webserver. In web design there is a clear distinction between 'front-end', the visual and content parts of the website and the 'back-end', the infrastructure it runs on top. When it comes to the web or internet infrastructure outside of professional circles, the material conditions are not discussed as resources are taken for granted or even completely virtualized. A low-tech website means this distinction between front-end and back-end needs to dissapear as choices on the front-end necessarily impact what happens on the back-end and vice-versa. Pretending it doesn't usually leads to more energy usage.
An increase in traffic for example will have an impact on the amount of energy the server uses, just as a heavy or badly designed website will.
# Hardware
* Olimex Olinuxino A20-Lime2
* 16GB SD Card Class 10
* 6600mAh Lithium Polimer Battery (UPS) (24Wh)
* 50Watt 12v Solar Panel
* Solar Charger
* Lead Acid Battery 12v (86Wh) discharged to max 66% to avoid deep discharging thus 30Wh
* USB to Barrel jack connector
* Custom power measurement circuit based around arduino nano / at tiny
