Pairing Static Websites with CMS
I’m going out on a limb by saying we may be on the cusp of a revolution as it relates to how we build, deploy and manage websites. That’s a strong claim, but witness the new Reese’s candy of web technologies: Static files combined with the content management system.
Separately each has a certain charming flavor along with any number of nutritional deficiencies. Together, though, they create a compelling recipe for the future of the web.
Static files
Static websites are built with HTML, CSS and maybe a few javascript files. The websites are “static” because the web server doesn’t dynamically assemble pages before serving them up to a requesting browser.
The files are served up as-is straight from the file system…right from where the webmaster put them after the files were created. There’s no server-side scripting going on, and no database.
Static websites avoid two big problems that we might face using some other approach.
First, static sites are blazing fast. A web server tasked with serving static sites can run circles around a web server bogged down with executing server-side scripts and making twenty-plus database queries per HTTP request. It’s an all-too-common scenario.
Second, static sites typically don’t expose the vulnerabilities that so often come with a site dependent on execution of scripts like PHP and ASP.net and running on the public Internet. Avoiding this complexity, a static website in and of itself offers hackers little in the way of exploitable security vulnerabilities.
The downside of static
Unfortunately, static websites don’t lend themselves to the serious work some might demand of, say, a mission-critical sales and marketing tool.
Let’s sum it up this way: Static sites offer no inherent build and management interface. Without providing a way for non-technical resources to manage content, static websites can hardly be taken seriously in some contexts.
Content management systems
Content management systems have been around and quite functional now for at least a decade. They are, themselves, sophisticated applications that typically run on a site owner’s web server. They were developed as a means to overcome the shortcomings of the static file approach to building and managing sites, and they represent a huge leap forward.
A few benefits that the typical CMS delivers include:
- User administration
- User authentication and authorization
- Flexible permissions schemes
- Content modeling
- Content entry and updating
- Content query and output
- URL handling
The list is hardly comprehensive. But even if the CMS did little more than what the list describes, you can imagine the immense value wrapped up in these functions alone.
The downside of the CMS
Despite its value, the CMS comes with its own baggage.
Untuned, a CMS can be disappointingly slow. The traditional solution has been to throw more technology on the stack in the form of high-performance caching mechanisms. In essence, these solutions create, you guessed it, a “static” version of the site, and serve pages from it in response to requests.
This averts having to go through the more resource intensive process of regenerating responses from from the database upon each request. Practically speaking, however, these caching solutions tend to be complex and expensive.
Performance isn’t the only common complaint of CMS users. Popular stacks like Drupal, Wordpress, and Joomla are often attractive targets for hackers.
To avoid nasty outcomes site owners often endeavor to keep their CMS current with security patches. It’s an effective, although expensive, proposition.
Static websites let us avoid deploying big and complicated applications where every hacker can try to work their tomfoolery.
A match made in Internet heaven
So what if we could assemble an approach to building, deploying and managing websites with all the benefits of static files — including speed and security — with the robust build and management capabilities of a tool like Wordpress or Drupal?
To be fair, variations of this approach have been in existence for years. But recently I’ve caught glimpses of what is apparently a resurgence of the idea.
The concept is simple: Build a website using a CMS, but rather than deploy the CMS directly on an organization’s public web server, we extract a static representation of the site’s output in the form of a complete file and folder hierarchy. This static version of the site is what gets pushed to the web server.
To conclude
Call me crazy, but once existing attempts at making this happen mature a little, I believe we will see widespread adoption of the technique. I can’t wait to explore some of the efforts I’ve uncovered thus far.
Is it a panacea? Of course not. Fact is, the most common CMS platforms fall short in other ways that beg a better mousetrap. But this is movement in the right direction, and Rome wasn’t built in a day.
What do you think of the idea of the static website?
MONTHLY MARKETING INSIGHTS.
Get thought-provoking and actionable insights to improve how your firm makes a connection with your customers.
LEAVE A COMMENT
[...] read more [...]
[...] read more [...]
We at Gizra are working on doing just that - pairing Drupal with static sites: http://www.gizra.com/content/drupal-x5-faster/
@Nir Yes, I saw this just within the past couple of weeks, and it was the primary catalyst leading me to write this post! I didn't mention it in this article only because I wanted to first have an opportunity to get my hands on it and understand how far along you guys are. I'm super excited to explore it, and hope you won't mind me reaching out to you for help or some comments before I write about it.
Thanks for reading and commenting!
Sure thing, we'd be happy to help you get acquainted with Zariz when you get some time.
Meanwhile, a video of Amitai discussing it with jam went up today, if you're interested: http://www.gizra.com/content/zariz-on-tv/
Old school way of doing this is to use the boost module. https://drupal.org/project/boost
@Nir, the video is great. I plan on recommending to others in the office. Thanks for sharing.
@mikeytown2 Thanks... have heard this now from a couple sources. While it doesn't address *everything* that some other solutions might, I'd still like to try it out for myself.
Funny to read this. Was my idea as well. I had a Drupal website but then realized it was doing lots of db dynamics to serve not-user-specific pages.
I now have a custom backend which produces new json files every 15 minutes (yes, its a very dynamic website !) and then use grunt / handlebars to produce new 'static' html files.
I think most websites not having user-specific content would be much faster (on cheaper hosting) with a solution like this. Instead of doing lots of calculations for every request (and putting a lot of effort in optimizing that), the calculations are done just once in a while. No expensive hardware needed.
@Gijs Thanks for taking the time to read and respond. Not surprising that great minds think alike. :-)
I agree this looks like the trend. However I cannot see how pushing a CMS site into static pages improves on using Boost, or a public-facing Varnish server, with a fresh cache (e.g. refreshed by crawling? An automatically rebuilt static site is in effect pushing static pages; a public-facing 'Boosted' or Varnish server in effect pulls them off the CMS backend. How is pushing static pages better than pulling them with Boost or Varnish?
@john_b So "better" is subjective, right? As someone supporting a good number of sites, the advantages from my perspective include (1) getting Drupal and its vulnerabilities off of the public web server and (2) eliminating the use of yet another technology (or module, at the very least). Simpler tools mean lower costs. But I wouldn't say "better", as my evaluation criteria won't necessarily be the same as yours. To make one other point, I LOVE Drupal... and have loved it for years. It's an awesome tool, and stands above many if not most of its peers. But it's power does not come without a few strings attached... as with any other piece of software.
Mark,
I think this is a great idea. I have been advocating for the use of semi-static content for a while. The first time I toyed with this idea and even used it to some extent was back in 1999 at an online retailer that we both know well! It is merely a form of long-standing cache.
Synchronization can still cause issues, and the fact that we are introducing another layer of indirection. We also have to realize that 'some' content needs to remain dynamic. For instance, we allow our clients to specify some sidebar ads targeting different pages (ie: the ski pass discount ad goes on the recreation/activity pages, and the bed and breakfast ad goes on the vacation planner page). This can be handled in a couple of different ways... Donut caching/partial page caching using a longer duration cached or static component and server side logic (yuck) or javascript (yes we use it quite a bit with the concept of a 'base page' that is rendered immediately without javascript with all the trimmings filled in later).
We sort of talked about the problems we have building CMS-backed sites that these approaches can solve a while back. Our custom 'mid tier' runs on Lucene and is a very fast cache, but not completely static.
Have you experimented with static content very much?
Brice, you're right, I remember now talking about the stuff you had been working on, and this necessitates further conversation! No, I really haven't toyed with static approaches much, and erected a new blog recently (http://figart.github.io) to play with one of the more common approaches, Jekyll. Let's talk soon!
Hi,
I definitely thinks that is the solution.
But here is my story about it:
I've worked for months building a solution that is able to host static websites easily, safely, and that is real fast.
But, when I first tried to sell it to web agencies, the answer was "That sounds good, but how the hell do I explain my clients they have no online admin interface?"
I then added a simple, made-in-one-day feature: The solution may now take files from the storage, or delegate to a URL. You can then benefit from all my pretty speed optimization tools (cache headers, caches, image profile striper, auto gzip...) And you can back your static website with a CMS, just playing some DNS tricks.
And it rocked. Apart one thing: CMS usually tend to use absolute URLs with hostname, and the likes, wherever they want. Time for a search-and-replace tool.
Now, I think I've come to a nice solution. But it has now grown with complexity, from what seemed a super simple fast-cloud-content-hosting-solution.
What do you think about my way to this cruel end? Would you like to try it and give me some feedback? Here it is: http://www.staticms.com (sorry, most of the content is in French, but I'm translating as fast as I can... First error was maybe to target French web agencies...)
Mathieu, founder of StatiCMS.com
PS: Here is a blog post of mine (in French, again...) on how you may use my solution to hide a wordpress install behind my solution to be "20h proof" (able to withstand nation wide TV news coverage... with your URL center, bold)
PPS: Sorry for below average English, I'm no native speaker
@Mathieu, pas de problème. Je vais jeter un oeil at ta solution. Merci d'avoir visité notre website!
You've got my email, should you need some demo account for testing purposes...
Would just like to add that many Information Security companies are now doing this (mine included). Some have even completely ditched the hybrid model opting for a full static build. Downside is you need a developer that is familiar with managing various Dev/Stage/Prod environments with CLI experience.
There's always a down side, right?