solar

More info: https://solar.lowtechmagazine.com/about/the-solar-website/#h... https://github.com/lowtechmag/solar/wiki/Solar-Web-Design https://homebrewserver.club/low-tech-website-howto.html IMO the only optimization they 'missed' is to pre-compress the static files and images on disk, since it's cheaper to decompress on-the-fly if the client doesn't support gzip. The could use zopfli to "extra compress" the most frequently accessed files, and use this as a solar dump load to usefully burn extra power when the batteries are full (perhaps compressing with gzip -1 when Pelican re-builds the static site, or even avoid pre-compression altogether during the build process. https://blog.llandsmeer.com/tech/2019/08/29/precompression.h... https://github.com/google/zopfli https://github.com/kurtmckee/pelican-precompress

> It looks like someome actually made an effort to reduce the quality of the images. For artistic effect, probably. They did, and it’s part of the footprint-reduction techniques used to host the site off solar full-time. https://github.com/lowtechmag/solar/wiki/Solar-Web-Design#im...

The webmaster at lowtechmagazine.com says: "...Compressed through this dithering plugin, images featured in the articles add much less load to the content: compared to the old website, the images are roughly ten times less resource-intensive..." https://solar.lowtechmagazine.com/2018/09/how-to-build-a-low... They go into more detail on their github page: https://github.com/lowtechmag/solar/wiki/Solar-Web-Design

Apparently the mix-blend-mode for images on the client is noticable performance-wise: https://github.com/lowtechmag/solar/issues/6