Getting back to static web

When the World Wide Web first became available, it mainly consisted of HTML pages and images residing on disk. Later, common gateway interface became available for more dynamic content. Static HTML pages still prevailed. Design was usually contained in each page. Design changes were difficult.

Content Management Systems, that tried to organize content and centralize presentation has become available in mid 1990s. It made publishing content much easier, but introduced new set of problems, such as page rendering speed, security, etc. First security issues were remote file inclusion vulnerabilities, followed by SQL Injection and cross site scripting vulnerabilities.

For simple web pages with mostly static content (with only dynamic part being occasional change of products, company news or blogs), static HTML is the most secure and fastest solution. Creating the HTML files should be done in a more modern way however. In addition to security, it makes it easier to replicate content among many servers in web cluster, adding load balancing and redundancy.

There are content management and blogging engines, that support exporting to static HTML. One such CMS is Alfresco Web Content Management. Stefan Marsiske’s blog engine Utterson is a minimalistic approach. Similar software based on Ruby is Jekyll.

If you chose to use a dynamic HTML engine, but the content itself is not very dynamic (no AJAX, etc.), it is possible to use wget to fetch web site content from central (secured and firewalled) CMS system. You need to think about rewriting URLs.

This is our approach with this website – it is managed in dynamic CMS, then static web is generated with a simple web script, distributed over geographic cluster and published. We currently use Litespeed webserver, but nginx could be used as well. Virtually unhackable (if operating system and webserver is kept up to date) and very fast (serving files and Litespeed has in-memory cache for most often requested files).

This may be seen as static HTML revival. There is no need to render pages from database in this case…

Related blogs