Even if it did save bandwidth, that does not equal significant energy savings. And if it did, there are better ways to save.
For example, looking at their response headers I see the image cache control expires after a day, plus has validation caching. This could be significantly improved. First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000). I get the HTML expiring after 24 hours, but images should be more aggressively cached. Validation caching always requires a round trip to the server, plus running validation rules on every single request so it can't save nearly as much bandwith and CPU as simple expiration caching.
Also, if they got rid of the those headers, plus the pointless `server: nginx/1.10.3` they could save over 100b per HTTP response. I counted 19 requests on that article, so it may seem small, but it can add up to a significant amount.
Hi I'm one of the people that worked on the webdesign, back-end and hardware. You are right about the caching, one of our strategies is actually to cache very aggressively. Not only for images but even for all HTML aside from the front page and about pages. This works for us since low-tech magazine only publishes a maximum of one article a month and the site spans a decade of content which won't change anymore.
However, since we were still working on the site at the time it got massively popular, we changed the caching settings in order for people to see the changes and fixes that we were pushing.
Cool, that makes sense. You should be able to easily turn off etags in your nginx config. This won't just save bytes in your response headers, but will stop a lot of HEAD requests to your server that are required to do validation caching.
> First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000).
Since it's a statically generated website, I'd favor never expiring the cache, and using cache-busting hashes instead. That way the cache is only emptied when the file actually changes.
It can be, but doesn't need to be as long as it is some sort of indication of the uniqueness of the content. A last modified date should work in the same way.
I agree. I feel they are doing it more for aesthetics than actual 'energy' consumption, but then they must justify why they are dithering, and "because it looks pretty" doesn't fit their shtick.
If you look at the non-solarpowered website, it turns out that TypeKit is serving a 830,8 KiB fullcolour PNG file. AAARGH. No wonder that they think they need to use dithering and such if that is their baseline.
I tried testing some variants and made a static HTML gallery on neocieties[1]. TL;DR:
- cleaning up the photo before filtering it makes a huge difference in image quality and compression.
- quality 80 JPG is 86,6KiB in color, 70,9Kib in grayscale.
- quality 40 (which is ugly but still has readable text) uses 44,8KiB and 37,8Kib respectively. The latter looks a lot better than the dithered image IMO.
- similarly, the grayscale PNG with pushed shadows and positioned dithering has readable text and contains significantly more detail at 4 colors and 38,7KiB than the 16-color 42,4KiB image on their server.
