Hacker News new | ask | show | jobs
by protonfish 2820 days ago
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.

2 comments

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.

I'll look into those server headers as well!

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.

Unfortunately there is no "never" setting. The HTTP spec recommends 1 year.
Isn't the etag just a hash of the content?
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.