Static vs. Dynamic Sites

The current storm in a teacup seems to be about static vs. dynamic website design. As usual, this is a False Dichotomy ... actually, there's a whole range of options to explore.

Different Types of Dynamic

Utterly Static
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 cached indefinitely.
Statically Deployed
Your CSS is probably compiled from SASS or similar, and your Privacy Policy, etc, pages are probably templated out of your CMS. Your Javascript may well be compiled from some more exotic language too. It can be handy to do this stuff dynamically in development systems, but when deploying to production you really might as well deploy the compiled versions as static files which change only when the site is redeployed. For example, this blog is statically generated using Pelican and then copied up to AWS S3.
Periodically Updated
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.
Dynamically Updated
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.
Utterly Dynamic
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?

Combining Types of Content

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:

  • Use a Periodically Updated index.html page with the front page content embedded in it for immediate display.
  • This page loads Statically Deployed CSS and Javascript assets, and some Utterly Static media assets too. Assuming the user has been to your site recently, these will largely return 304 Not Modified.
  • The Javascript can then load the user profile[*]_ from a cache of Dynamically Updated user profile JSON docs. This data can then be used to customize the user's experience.

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.