I am currently looking into improving a system that (like many systems)
generate static content at runtime.

I have always been against generating static content at runtime and
believe static content should be generated by a cronjob or manually at
some idle time (if possible).

This will provide real static content (no PHP at all) that doesn't need
to be checked every time a request is made hence a huge performance
benefit is achieved.

A nice article on the issue:

Quote: "The moral of the story is never make the user pay for your
laziness. Do not use the application tier of a website to dynamically
generate static content at runtime. Instead do it at publishing time or
even do it in a daily or hourly cron job. This approach allows you all
the advantages of using application logic without drastically reducing
the very web performance you were trying to improve in the first place!"

Sometimes however many pages are linked together and when working with
a system with hundreds or thousands of pages re-creating a lot of
content each night perhaps isn't always the best way to do things.
Especially if the content needs to be updated right away and can't wait
for the nightly cronjob to do its business.

To illustrate with a simple example..

A blog system with a menu that displays how many posts exists in each

- Home
- About
- Tech (412)
- News (2030)


When a new page is added to the News category every single page in the
system needs to get updated in order for the menu to display the new
number (2031).

Some use a compromise to include only changing items (like the menu
in the above example), but that would mean using PHP and not serving
pure static content.

Others use "ugly" solutions like frames.

Care to share your experiences and recommendations on the issue?

Kind regards

Kim N. Lesmer
Programmer/Unix systemadministrator

Web    : www.bitflop.com
E-mail : k...@bitflop.com

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to