December 30, 2003 | View Comments (12) | Category: Web Mastering
Summary: Why don't we see more sites implement static pages over dynamic?
The wonderful thing about MovableType is that it creates static files for your entries. There are numerous advantages to this and I wonder why you don't see more sites implement this kind of stuff. Is it too difficult?
With static files you get assurance of having a quality filename, assuming you setup your system properly. This is becoming a huge issue because from a usability standpoint there are many people who beginning to see the value in a webpage having a memorable address. Most dynamic sites you are greeted with an url of:
http://www.yahoo.com/prod?=x534akdf9483ad=34kjxkvad
Thank god for cut & paste.
Another advantage that static files holds is the fact that Apache simply kills static files. That is what it specializes in. I can't speak for other web servers, but I know Apache prefers static over dynamic files. So there is a big performance boost right there if you are dealing with a site that has multiple pages. The downside to this is that the web server storage begins to grow if you have an insane amount of pages. Granted it would take a lot, maybe Amazon type size of site for this to warrant any concerns.
The content for these entries is all static and the only dynamic stuff that happens comes from some include files. I tend to think this is part of the reason the site loads so fast. There are some type of sites that would simply require dynamic pages such as financial sites that update their content consistently. However, I don't see what the problem would be doing this on a news site.
I am far from a server/webmaster type expert, but I am unaware of any clear advantages that dynamic files would have over static files. I am sure it's because of the holidays and I am not thinking straight, but I am missing the bigger picture here I guess. Why don't more larger sites implement these features?
Trackback URL: http://9rules.com/cgi-bin/mt/mt-tb.cgi/89
On larger sites do you think it would be easier to troubleshoot linkrot as opposed to a dynamic site? I mean looking in the error logs and seeing elephants.html no longer existing is much easier to figure out than x4sdxc343d09ad3.cgi or something.
Scrivs (http://www.9rules.com/whitespace/)
I think you are making a very broad generalization about dynamic vs. static pages. It looks to me like you are comparing one particular aspect: displaying the correct content based on a parameter that is passed in to the dynamic page. In this case, I think you are correct, a static page is probably better because it will always display the same thing for a given parameter. The problem here is probably that there are no good off-the-shelf system that generate static pages like MT does.
My point, though, is that a dynamic page can do much more than read in passed parameters. It can check that a user is logged in, show saved customized settings, show whether or not a product is in stock or not (without having to wait to re-build every static page), perform different actions based on day or time, etc.
On my sites, I've tried to determine which pieces change infrequently and create static includes automatically (ie. nightly cron jobs).
I don't think there is a right and wrong in this case. Both have pros and cons and the right one should be chosen on a case-by-case basis.
Jason Long (http://www.antdesigns.net)
As for the linkrot question, I doubt you'd have a page named x4sdxc343d09ad3.cgi. Much more likely, you'd have a parameter passed in like so:
elephants.php?id=x4sdxc343d09ad3
In which case, if you were seeing 404s, it would be because elephants.php is missing - no different than elephants.html.
Maybe I misunderstood the question though. My apologies if so.
Jason Long (http://www.antdesigns.net)
I dunno. Personally I don't like the way MT uses static files; though you've obviously proved one of the reasons I dislike them wrong (redesigns requiring reworking of all the static files). I find dynamic stuff much easier to work with. It gives you more freedom to embed data and so on.
As for yahoo store... you certainly wouldn't want to try and maintain a static shopping cart, would you? I mean, if you have a dozen items that don't change, sure, but if you have hundreds?
Of course, since 'dynamic' and 'static' have multiple possible meanings, a definition of them is probably needed so we're speaking the same language. For instance, when I say "dynamic" I usually mean "database driven" but could potentially mean simply "php/cf" instead of straight HTML.
Benefit of CF/PHP design (or even SSI for that matter) over straight HTML in any site, informational or otherwise -- include files. If you change your headers and footers (not just style changes for which CSS could arguably be used, but things like changing or adding things), pages that use an include, you change only the include and the whole site changes instantly. If your site is straight HTML, you have to change every file, which takes a while, even with stuff like dreamweaver templates.
And then, you have to upload the entire site to the server... and get the:
oops, but not that file... and not that file... oh, shoot, and not that entire section... oh, hell, I have to undo the changes I made to these 40 pages that link to the new section, too...
and so on. Been there, done that. Multiple times. (O holy SEC, you could star in The Shining)
Part of that is poor initial planning, of course... but it will all go away when we redo the site using includes or maybe Fusebox.
JC (http://www.thelionsweb.com/weblog)
Ah, yeah, and on the URL issue... for something like an ecommerce site, there's nothing wrong with URLs like that. No one is going to try to type in the URL for a given product. For blog articles, news stories, etc... it's still not really an issue. It's rare to type out long URLs, we copy and paste them or go to the root and navigate. The human-readable URLs are nice because search engines like them and because if someone emails you 9rules.com/godhelpusall/goatse.php you know not to click on it; or if it's static_vs_dynamic_files.php we know what it is before clicking... but it's not really a tremendous benefit.
I think my blog can do filenames like that, even if it's not MT... just a setting that I'd have to change (but which won't work right now because I customized some code in the app). They wouldn't be real files, of course, just masks, but for the end-user, there's no difference.
As for the performance issue, the difference is so incredibly miniscule it's not really worthy of note, as long as your server and database server have a reasonable level of performance, which is also required for static (sans db, of course). Plus, with php at least, you can use gzip to speed the file transfer. Stuff on my blog loads generally in under 1/10 of a second; on the PHPBB I run, it's even less than that (phpbb is more complex but also better optimized). So unless you're serving a really excessive number of pages, the performance gap is negligable.
That reminds me... you're using php, not html. Apache is tweaked for straight HTML, not stuff that has to go through PHP. So unless you dumped PHP and have type .php set to text/html, you're not actually seeing the benefit you've noted.
JC (http://www.thelionsweb.com/weblog)
Is it too difficult?
For some programmers, yes.
For most, though, there's no way to convince the clients that "pretty filenames" and a slight performance boost are worth the many extra hours and dollars of developer time.
Joe Grossberg (http://www.joegrossberg.com)
Dynamic pages are for *dynamic* content, the kind of stuff it will take more processing power to regenerate the entire site when it changes than to generate only that one page.
On the other hand, there NO relationship between the nature of a page and its URL. URLs are parsed and interpreted by the server, and if I want to, I can simply have somePage.html interpreted as a JSP form, and so on.
URL are meaningless in themselves. It is the developer which gives them meaning.
There's also the issue of POST vs. GET and so forth.
Gabriel Mihalache (http://www.individualism.ro/)
Yes, serving static pages from a database is truly silly, but the issue of static vs. dynamic is not black and white. Sometimes the best solution is a mix. A wonderful case in point is the PHP templating system I've developed for maintaining a 400 page site with both static and dynamic pages. The essence of the system is that each page you request has its BODY and HEAD elements copied and pasted into a template specified in a META tag. Additional META tags control the inclusion or behaviour of other elements within the template, and the META tags and include files can be defined at any level of the directory structure from which point they cascade downward. So every time a page is loaded, the driver script does quite a bit of reconnaissance through the file system. The site I maintain is on a dedicated server and has served a maximum of 25,000 pages in one day, so the performance isn't a big problem. However, because I plan on releasing this templating system as an open-source web development tool, I felt a caching system was necessary to improve performance. I wanted it to be automatic, so that the entire site need not be rebuilt manually every time a change is made (I do frequent minor updates that must be reflected immediately). Yet, a page can be built from many files, any of which may change, so all of the dependencies must be compared to the timestamp of the cached copy.
The payoff has been huge. What I have is a completely dynamic site that essentially serves static pages. The really slick part is that the templates are built by reading the files in as text, rather than including them as PHP. That means that the engine can output PHP into the static file, so the system can cache all of its work without caching output that needs to be truly dynamic (eg. database apps, etc.).
The next feature that I'll be adding is the ability to output an entire site statically. This will mean that the system can be used as a web development tool for sites that will ultimately be deployed in a static environment. Once I complete this and the documentation I plan on releasing it as open source software. It works beautifully with Movabletype, so I expect a few of you in the webby community will find it useful.
Gabe (http://www.websaviour.com/)
Seems to be one of those issues where "to each his own" is applied.
Scrivs (http://www.9rules.com/whitespace/)
Another benefit of static pages is there's less that can go wrong - you're only relying on Apache and the server & connection.
Both have their place - it depends more on if you have dynamic content and what tools you're using. Of course having everything generated from a database is usually a good thing, whether you're generating dynamic or static pages.
URLs shouldn't be an issue:
http://www.9rules.com/whitespace/web_mastering/directory_structure.php
http://oli.boblet.net/2003/12/29/urls
For MovableType if you don't like the rebuilding associated with every template change, check out Smarty:
http://smarty.php.net/
Brad Choate uses it (must be good! ;-)
http://www.bradchoate.com/past/001041.php
Or you can test on a local machine before uploading - always a good plan.
oli (http://oli.boblet.net/)
Static files can kill your structure. What I plan to do is a mixture between the two: I'll have a showpost.php page and pass it a parameter to tell it what files to grab from. All my blog posts will be stored as XML files (tucked away in some subdirectory), and I'll use XSLT (possibly generated on the fly) to transform these into viewable content, which will then be echo'd back into a page with PHP. The paramater that gets passed will be a timestamp. At the moment it's in an unreadable format, eg 134720190303 which equates to 20:47 and 13 seconds on the 19th March 03 (secs, mins, hours, day, month, year: two digits for each). I may change this to a more memorable format.
David House
Keep track of comments to all entries with the Comments Feed
©2003-06 9rules, Inc. | Thoughts Feed | Notes Feed
Amazon Stores: Powertools | Jewelry | Books | Health | Landscaping | Kitchen | Movies
#1
This is one of the reasons why Movable Type is so great. You almost get the best of both worlds.
In any case, I've had heated discussions over this very issue and it usually comes down to over-engineering. For some reason, some developer, sys-admin types see dynamic as a clear cut advantage in every case. But as you imply, in many, many cases it's just simply not needed.
There is nothing wrong with going with static files. We did it (for the most part) with our redesign down at the hospital and I'm finding that the static files are much, much easier to work with than the CMS driven stuff we have. And really, at the end of the day, there isn't any value in having most of our stuff be served up dynamically.
What's more -- we're slowly moving out of our CMS to static files. Mostly because they've been a hassle both to the user and to those folks who maintain the site.
It really depends on the size and scope of the project but I can attest to the fact that using static files for a huge, complex informational site works just fine.
Keith (http://www.7nights.com/asterisk/)