Coyotes Designs

Have you decided to implement a WordPress caching plug-in in the hopes of increasing the performance of your blog? I will soon be receiving flack from caching proponents for what I am about to say. This is strictly my personal opinion, and you may or may not agree with it. But here it is nonetheless.

When web content first became available, you had little option in generating the content other than writing your article by hand, including coding the necessary SGML tags for the desired layout. This content seldom underwent modification -- The content is generally static in nature. More often than not, the layout wasn't what needed to be changed, rather, additions or modifications to the article information, or data, was what was required as new information and data became available. Months passed between these changes.

Later in the conceptual life of the web, Someone had the idea to implement dynamic functionality. In this specific instance, I am referring to PHP¹. The end result of this new technology allowed a site owner (operator, writer, whomever) to more easily maintain the previously hard-coded articles and related content, by separating the static HTML code elements from the newly created dynamic "tag" information.

¹...a very simple parser that would pick tags out of HTML files and replace them with the output of the corresponding functions in the C library.

What purpose, then, does caching serve? In its barest form, caching turns what was designed to be dynamic back into static in the hopes of presenting site information more quickly to the reader. The decrease in server resources in order to produce this dynamic content is also a goal. The need for such functionality was desperately sought after way back when computers used for web deployment were evolving. Nowadays, however, web server performance has exponentially increased from the, at best, 486's with 256K on a T1 days of the '90s.

Caching can help site performance in such circumstances where server resources are limited, or very little content requires changes. This does not, however, solve the issue of truly dynamic content, such is the case with the WordPress cd-ad-sponsor plug-in, where information (in the form of sponsor advertisements) is changing each time a page is requested by a reader. A single ad presented to a reader changes each time that same user requests that same page.

I wrote the cd-ad-sponsor plug-in to solve one problem, that of managing sponsor ads on WordPress blogs. I wanted the ability to inject sponsor-specific advertisements into what is, simplistically, static site content. For example, having different sponsor ads displayed in the header section of a WordPress blog effectively makes the static header information dynamic. Why, then, would I choose to cache this header?

I am not saying that you should not implement some form of caching mechanism should you feel the need to do so. What I am saying, is that it makes no sense to do so in my particular instance. If you wish to cache your WordPress content, I must point out that there are a number of applications, such as OpenX (which, I highly recommend) that accomplish similar results for any type of web site, whether it be strictly a forum, or a blog. I do intend to increase, or tune, the performance of the cd-ad-sponsor plug-in over time, but I do not plan to support its functionality in conjunction with caching mechanisms.

Leave a Reply

You must be logged in to post a comment.