In the publishing world, there are two main methods of distributing content, and they’ve flip-flopped over the centuries. Until Gutenberg invented his printing press in Germany, if you wanted a book, you would order it, scribes would copy it, and in a few months to a year, you’d get your copy. Print-On-Demand, or Just-In Time publishing, in its most rudimentary sense.
Then Gutenberg came along, and made it much quicker to print copies, or rather comparatively quicker, as that advantage came from being able to set a page of type, and run one or two hundred copies at once, in the same time that it would take a scribe to make one or two copies of a page.
Since the increasing speed of printing through the past five hundred years, eventually advancing to phototypesetting and offset printing, people have returned to Print-On-Demand or Just-In-Time printing through services such as LuLu and the like. The cost to manufacture a single copy is slightly higher, but with very little delay between deciding to print it, and holding the finished product in your hand, it is often more worthwhile to pay a slightly higher cost per copy, rather than risk a much higher amount of venture capital, should the book be a flop, and you find yourself with a garage full of unsold copies.
Web publishing has largely followed this trend.
In the early days, people would write HTML pages by hand, and post them for visitors to read. The Gutenbergs of their day, they spent a bit more time initially, to enable easy distribution of the finished content. Web Servers did not need to rebuild a page each time a visitor wanted to view it, it just needed to yank the file, and pass it along.
As servers got faster, databases more accessible, and scripting languages more powerful, we pushed more work off to Just-In-Time publishing, and it is the most pervasive method in the Content-Management System world today.
Thinking of this, my mind immediately drifted to WordPress due to its ubiquity, but this could just as equally apply to any other system, such as Joomla, Drupal, Kentico, DotNetNuke, or their ilk. While most do offer caching methods, either through built in capabilities or plugins, the underlying principle is the same. It takes a given amount of processing time to save content via the back-end, and a given amount to generate the pages for user requests. If these times are roughly the same, if you figure on an average time span you have five updates and a hundred views, the total processing time is as follows:
5x + 100x = 105x
Even if we figure conservatively that it takes four times as much processing time to do an update as it does to present a page, the math goes to this:
( 5 × 4x ) + 100x = 120x
Now, we do have another option in this. Systems can front-load their content. It may take a bit more processing time to make an update, but not by much. If the CMS db is hosted off a server other than the one that the files are hosted on, it will likely have an even greater savings. As per our previous math, let’s assume that front-loading the content into static HTML pages takes six times as much processing time, but as little to no processing time is expended on page displays, estimate that takes one fifth the time. Realistically, it would take far less, but for argument’s sake, one fifth.
( 5 × 6x ) + ( 100 × 1⁄5x ) = 30x + 20x = 50x
Now, consider two more factors. First, consider that your average site will get far more than twenty hits for each time someone makes a change to the content. This amounts to significantly higher savings. Consider also that your visitors, both of the fleshy and googlecrawler varieties, will judge you unfavorably if your site takes too long to load. This load time can be significantly decreased if the pages are just sitting there, waiting to be served up, rather than having your server’s ‘scribes’ write a copy from scratch every time someone requests one.
So, for starters, use caching on your CMS. It’s not a complete solution, but it’s certainly better than hand-writing the Bible each time someone wants to view your site. And if there are any Content-Management Systems that actually do store the content in a DB, but then produce static html pages, let me know in the comments below!