In the case of some of one of our CMS's there is always some database traffic but the initial traffic is to determine if the object in the database is more up to date than the one in the web server cache or file store.

If the component in the database is more up to date than the one in the cache/filestore then the database component replaces the cache component.

Keeping stuff up to date on CMS sites is always seems to be a bit of a problem because you have to contend with the proxy server as well as the black magic that goes into the CMS caching.

As far as bog standard ASP/HTML sites are concerned I have had some success with sp_makewebtask and sp_runwebtask but if the worry is the load on the database server then sp_makewebtask/sp_runwebtask are probably not the best procedures to utilise.

You cannot eliminate database traffic altogether.  The questions that I have to ask are

• What is the traffic for rendering a dynamic component?
• How long does it take a process to build a static component?
• What is the overhead in querying the timestamp on the static component?

It may turn out that the traffic involved in rendering a dynamic component is lower than the processing involved in working out if a static component is out of date.  In this case you would be daft not to use a dynamic component.

We tend to use the static component approach for objects that would normally require a larger processing load, but are themselves, mainly unchanging.