The basic statement I was trying to make was "due to disk caching, putting your cache in memory or disk is roughly equivalent, except it's easier for the kernel

The basic statement I was trying to make was "due to disk caching, putting your cache in memory or disk is roughly equivalent, except it's easier for the kernel to make decisions about an on-disk cache." As far as re-executing templates, let's break down some hypothetical costs, including pretty optimistic network latency. 1. Accept, read, and parse a request from a socket: >50ms 2. Read a template from (solid-state) disk: 16µs 3. Parse and execute a template: 100µs 4. Serve the response over TCP: >20ms If we replace (2) with a memory cache (whether it's your app or the kernel), the cost goes down to maybe 1-5µs. Your time-to-response is effectively the same with template caching. So what's the point of a generated static site? Reducing CPU and memory pressure. Your page load times are almost completely bottlenecked on network, so you can optimize this using a CDN/external caching service (like Cloudflare) to bring the content closer to the user, or you can optimize by removing CPU cycles per page load to increase the number of concurrent connections you can handle. There's a point where the userspace to kernel latency in serving a file is also a bottleneck, but nginx can use the sendfile() [1] system call to copy a file directly to a socket (from the kernel disk cache) without ever touching userspace, which is much faster than anything you're going to do with in-app caching, unless you also put the TCP stack in-app. [1] http://linux.die.net/man/2/sendfile http://linux.die.net/man/2/sendfile