Your CMS Is Not Your Web Site

A content management system is a centralized repository for your content. A Web site is a composite of decentralized fragments that are assembled on the edge, in just-in-time fashion as the content is being delivered to users. If it's not a Web site, what does a CMS do?

First and foremost, the job of a CMS is (not surprisingly) to manage your content. It keeps content in raw form, separate from the presentation layer in which it eventually should appear. A CMS also allows you to deliver content in multiple formats, such as JSON, RSS and Atom feeds. Many legacy and proprietary content management systems rely on creating static HTML output to use for a Web site, but most newer or open-source content management systems are developed in a way that they can be queried directly and return Web-friendly markup.

As is often the case with PHP content management systems, such as Drupal and WordPress, the CMS can output content via a Web server. This leads to the perception that the CMS is, in fact, the Web site. In the case of small Web sites, the difference is negligible and not worth discussing. However, for larger Web sites (and most certainly for enterprise sites), the difference becomes unavoidable. A CMS like Drupal is installed in a Web server's docroot, and content is requested just like any other Web page. A good CMS will handle things like granting users access to content, content administration, theming and even accepting user-submitted content, such as comments and blog posts. Apache accepts a GET request and passes that on to Drupal, which then interprets it using a variety of menu callbacks to determine which content is desired. It's smart enough to check user access controls first to determine whether the requested content is allowed, and then decides to deliver it. The theme engine within the CMS renders HTML around the content and returns an HTML document back to Apache for delivery to the end user.

So What Is a Web Site?

Broadly speaking, a Web site is a collection of HTML documents that interlink to other pages that let users easily load related documents. But in its more abstract form, and in the form most people expect from a Web site, it is the location on the Internet that users interact with using a Web browser. What the user actually interfaces with could be static HTML files, HTML generated via PHP, page updates using AJAX and JSON data, or even Flash or Java plugins fetching content from a Web service.

In the end, a Web site is that huge abstract thing users see and interact with when they put your URL in their browsers and something comes back. While clicking around your Web site, looking for the information they're after, end users have little to no concern about HTML or your CMS; they care only that the content is delivered in a seamless fashion.

Although the content itself makes up the majority of the Web site, there also are ancillary components that go along with serving that content. This necessarily includes the Web server, content distributed networks (CDNs), front-end cache systems and even Web browser support. All of these things may change what users see after the content has left the content management system.

It helps to think of your Web site as being composed of several categories, or buckets. Your content management system is, indeed, a bucket unto itself. You also should have buckets for caching (Varnish, CDNs and Memcache). Additionally, you may have another bucket for hosted integrations, such as Facebook and other social network plugins, comment systems and statistical analytics. There even may be buckets for mobile apps. Every time visitors view a page from your Web site, they are pulling from each one of these categories.

However, as far as the Web server is concerned, the "end user" in question may not actually be the person sitting at the Web browser. The requester may be a load balancer that manages requests to multiple Web servers that serve the same content. The load balancer then in turn returns its version of the document to a front-end cache like Varnish or a CDN. Varnish reads the content and decides that additional holes need to be filled and fetches more content.

Why Should My Web Site Be Decentralized?

Content management systems written in templating languages tend to be very fast to develop and are quick to update with new content, but they have performance concerns as a result of their tendency toward frequent dynamic page generation. For small amounts of traffic, internal caching is usually sufficient. Even serving static content, Web servers can scale only so far, as they have very defined hardware limitations--the amount of available RAM divided by the amount of memory allocated to a thread (like with PHP's memory_limit value) determines the maximum number of simultaneous users that can access the server. Adding multiple Web servers behind a load balancer, enabling front-end cache and using a CDN will improve the scalability of the Web site significantly.

Adding more buckets increases Web site capacity. Adding more buckets also changes the results of the request from the CMS into what is ultimately delivered as the Web site. This is where edge computing becomes an integral part of your Web site. To improve performance even more, it may become necessary to move some components, such as user registration and commenting systems, out of the content management system entirely, and place these things in some of your other buckets. For instance, a common approach is to have the CMS serve user-agnostic content with placeholders for the "Welcome so-and-so" messages. These placeholders can be edge-side includes (ESIs) that then are replaced by user-facing cache systems. Varnish and most CDNs support ESI by default. ESI fragments literally can live anywhere else on the Web, such that it's no longer a requirement for the CMS to manage user registration, much less even be aware of it.

Edge-side includes (for example, <esi:include src="" onerror="continue"/>) are very similar to server-side includes (SSIs) when dealing with static HTML files served by Apache. ESI is a standard of edge-side computing and caching systems. This makes it possible to manage content in your primary CMS, manage users and user-generated content in a secondary system, and include other outlying content from tertiary systems. With this approach, your Web site actually may consist of several disparate content management systems assembled on the edge prior to delivery to end users.

Once this page is assembled and delivered, this still may not be the Web site with which users ultimately interact. Once the content is delivered, the client browser may make even more alterations. References to JavaScript on the page may invoke widgets and other hosted integrations, such as Facebook "like" buttons, social-media "share" buttons, feedback forms and user commenting systems. Using jQuery and other JavaScript frameworks are a common way to invoke additional content delivered from other content delivery services without your content management system having to control any of it.

Software as a Service (SaaS) is another bucket that sometimes makes up a Web site. Using on-demand functionality like SaaS, you easily can handle decentralized elements, such as user comments or breaking-news alerts. In this case, AJAX makes additional requests to your service and interprets the JSON response (because why must a CMS deliver just HTML?), and jQuery renders the results into the existing page. With SaaS, it is ultimately the browser that adds the finishing touches to the conglomeration that is your Web site.

http photo via


As one of Phase2 Technology's Senior Developers, Tobby Hagler builds platforms for clients while tapping into his extensive experience with Drupal-based websites. His expertise spans the gamut of technical capabilities.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Is a CMS a website? Yes I

WebDesignMalta's picture

Is a CMS a website? Yes I believe the definition of a website is just an amount of data accessible via an external ip to the public. I do not think that we could call a website a "website" if it was accessible internally, am I wrong on that?

As Cuisine Thai says, it would be a great idea to have a battle between Drupal and Wordpress. I personally prefer wordpress because of the huge amount of plugins and themes available on the net.

content management system

UK's picture

"Teaching certain clients how to use a CMS is a little like teaching a dog how to use a vacuum cleaner. No offense, but it's a petrifying task for all. So hurray, you guys just made our web studio's life so much easier!

concrete5 is revolutionary in simplicity. Our clients are impressed, less scared, and a whole lot more independent which means we can concentrate on design and programming instead of wasting a ton of precious time training them. Awesomeness!"

Thanks for the information. I

Nate Dunham's picture

Thanks for the information. I learned a lot just by reading your posts. Keep it up!

Forex Broker Reviews

Latest Medical News

Abigail Giri's picture

I'm doing some investigation on the similar subject. This was of actual support.

We use a CMS system now to

Regor's picture

We use a CMS system now to serve up web pages to customers in a secure environment. The next step for us will be to see if we can integrate our ERP system data and serve that up as part of the content delivery. We have a few obstacles to overcome, and are writing an API that should address most of these. I think this will be an awesome resource for our clients once we work out the integration. I'll report back when we get closer to a finished solution.

Regor Otto
ERP System Manager

One important "bucket" that I didn't note (désolé si qqun deja d

Robin L. M. Cheung's picture

Whilst you did cover the essential concept of different roles being covered by these different "buckets," such as Memcache (most suited ostensibly to database-driven portions of the "web presence") and CDNs (most suited to large-scale distribution of very static content, such as media)--but one intermediary concept that is arguably an important portion of many web presences is the squid caching proxy.

Not only is it useful for load balancing and architecture-masking, but it is perfectly-suited to the intermediary case (critical thinking is so underrated these days...and synthesis even more so...)

Wikipaedia is one notable exemplar that uses squid extensively owing to its content being largely "static" pages, but the content on these pages, unlike video/media content, is apt to change at any time as contributors modify, add to, delete content. squid can sit between webservers and serve content that has not changed, reducing load on the very web server itself, in reverse proxy roles.

Beg to differ

itsbruce's picture

Maybe you aren't familiar with Varnish, but it is essentially a specialised version of Squid (focusing purely on HTTP). So that kind of bucket was actually covered.

agreed been trying to explain

Watch TV Online's picture

agreed been trying to explain this to people forever.

Ha, very crucial topic

webdesign's picture

Ha, very crucial topic though! I kinda interested to read that nice input. I have been long since user of linux. I have found content management system really accessible indeed. Thanks!

Bad Journal

Dave Keays's picture

"Using on-demand functionality like SaaS, you easily can handle decentralized elements, such as user comments or breaking-news alerts"

Suggesting that anything that requires user data input without the established and tested frame-work like a CMS is irresponsible at best. Like encryption, you are opening a security hole by trying to reinvent the wheel.

Properly invoked CMS' natively protect users from injections, session highjacks, and other things that would take much more effort to protect against in pure server-side scripting system. I'm not saying that PHP can't be hardened, but it is harder to do and therefore easier to skip. Nor am I saying that security blunders can't happen in CMS's. That is why the open source part of the equation is so important. You then get completely non-biased and transparent security reviews by outsiders.

Dave Keays, freelance webmaster

Why isn't it a web site?

Dave Keays's picture

Saying a CMS based site isn't a web-site because what is stored on the server isn't what is presented to the user is like saying that only programs written in machine language are programs. I'm sorry but it is another layer of abstraction (6th generation) in an already established chain. It isn't written in pure HTML/Javascript/CSS just like most desktop programs today aren't written in the CPU's OP code or microcode.

Saying it isn't a website because it has limits and is not infinitely scalable is absurd since every component in a Internet system is not completely scaleable. Does cat5e cables have a speed limit? Does the browser on a computing device (desktop computer, mobile device, etc) have a limit even with infinite RAM available?

Also, Drupal is being used in enterprise situations (White House, Sony, Fast Company, etc) which proves the implication that it is not doesn't pan out in the real world.

Dave Keays, freelance webmaster

What is a CMS

W. Anderson's picture

I found the article "Your CMS Is Not Your Web Site" very interesting, as it confirmed my thoughts on which Web development tools -aka CMS/Portal solutions to use for the broadest range of my clients' needs and requirements.

After installing and evaluating several Free/Open Source Software (FOSS) CMS over the past three years [Note: I am not a web developer] - including the more popular Apache/PHP/MySQL based CMS, three Jave CMS/portals, three Python based CMS (two with Zope Application server) and even a Ruby-on-Rails product, I determined that Plone CMS/Portal made the best fit for 'scalability' you mentioned in article, plus flexibilty, very good security model and is extremely modular and powerful.

In almost every aspect of your article description of disparate CMS functions, Plone is a good choice and has never disappointed.

The only major drawbacks for many "small website" clients are (a) there is a severe limitation of 'great looking' themes available - bothe Free and for purchase - requiring custom development, and (b) that Plone and Silva - another Python/Zope application - cannot be hosted in a "shared hosted" environment, resulting in increased hosting costs - minimum $30-$35 per/ month and up for VPS or dedicated sever hosting.

I like the explanation you provide.

W. Anderson

cms VS

CuisineThai's picture

It would be interesting to get "battles" between various CMS'
like Drupal VS Wordpress
Joomla VS WD ... and so on
As i do develop websites, i usually use Worpress, and focus on it, and i don't have time to check wether other solutions may be good ones. But i would like too be able to do this comparison...

an idea for an article ? ^^


diogo's picture

If you feel like trying another CMS, take a little bit of time to have a look at ProcessWire. While being very powerfull, it has a low learning curve. And you will find things that you don't find in Wordpress, like custom fields, and DOM like page handling (yep, just like jQuery selectors)


Ayesh's picture

It's no surprising that LinuxJournal is focusing on Drupal.
Comparing Wordpress and Drupal is now similar to Apples and Oranges. Wordpress is going in a way that Wordpress is the site. Among millions of Wordpress site, it's very easy to find sites that use same theming, slideshows, etc.
Drupal, in other hand, very difficult to get up but fina product is unique. it's unlikely that someone will go Drupal to host a simple blog (although I've done) with Drupal. So it's now making a framework. Not the web site itself.

However, your writing on "So What Is a Web Site?" is something related to Wordpress.
Web is not a collection of content anymore. Sometimes it's a presentation of content, but we should't forget services that has no specific content to deliver but a service -- like which is a pretty cool and useful Drupal site.