mod_disk_cache and mod_mem_cache make that pretty irrelevant.

http://httpd.apache.org/docs/2.2/mod/mod_disk_cache.html

re:edit hxincl uses a similar style as ssi but with a couple of enhancements:

http://manpages.ubuntu.com/manpages/trusty/en/man1/hxincl.1....

if you want exactly SSI syntax, ain't nuthin' stopping you from pointing curl at localhost.

They'll be infinitesimal faster for the server which will sit idle most of the time anyway... and much slower for you when you make a minor header/footer mod locally, and then you need to re-upload all pages that have a header (i.e. all pages).

I'm sorry, but this project feels more like "art" than a practical tool.

Plus, with a few basic lines of PHP (available on every shared host) you can pre-generate your site statically as well (and on the server, to save you the re-uploading).

Presumably the 're-upload all pages' bit can be automated. As far the reset, the trade-off depends on how often you're updating content versus the amount of traffic coming to your site; in many cases, a tiny saving on frequently-occurring page delivery is well worth a big delay on one-off page generation.

So basically, we've gone down a path of solving problems we've created ourselves.

rsync will easily handle a few lines changed in a large number of files.

Or you could just, y'know, run the static site generator on the server. What Linux doesn't have Python installed?

or you could just, 'y'know, run SSI. what web server doesn't have SSI? What problem are we actually solving here?

Serving pure HTML files off S3 is pretty popular. No SSI there.

https://news.ycombinator.com/item?id=7432097 also, which is it. are we on s3 or on a linux server with python?

nginx?

Ha, color me surprised then :)

It's best practice to not use the term "best practice" these days ;) (sorry, couldn't resist)