Media assets such as
founders-in-garage.jpg are utterly static.
They may hopefully one day be replaced by prettier assets such as
founders-on-yacht.jpg but in the meantime they can be thrown
directly into the repository, deployed out to a CDN and
Some content changes periodically, but not often compared to the number of times it is read. For example, a news site might update its headlines every few minutes. Rather than having every request for the homepage hit the database every time, just to see if anything has changed, it can be worthwhile to take periodic snapshots and serve them up as if they were static files! The HTTP ETag mechanism makes it easy for browsers to detect if anything has changed before loading the content again.
Even content which changes too quickly for this to be a practical approach can benefit from a caching layer. Whenever objects are updated, throw the fully serialized HTML / JSON objects into a key/value store. You can use a filesystem, or (for example) NGINX can read directly from memcached.
Well, some stuff is always going to have to be generated fresh every time. Individualized views, custom searches, that kind of thing. But it is the exception to the rule: 99% of your user interaction probably isn’t that dynamic! And if your data really has to be that fresh, perhaps you need to be looking into Websockets instead?
Not only are there a whole range of different levels of dynamicism to choose from, your site can combine them as appropriate.
For example, your news site could:
index.htmlpage with the front page content embedded in it for immediate display.
304 Not Modified.
Making this work elegantly may involve some messing around with Cache Manifests and Cross-Origin Request Sharing but it has the potential to radically decrease the amount of infrastructure you have to deal with to handle page views.