Balancing what processing happens at HTTP request time (the end user loads a page) versus what happens when the content management system outputs at publish time is the lynch pin of a performant, scalable publishing system. We'll use this vocabulary:

Baking

This is the publish time commitment of data to a file (or a more efficient cache, if you have one). Editorial narrative, headlines, datelines and other pieces of editorial/business data that doesn't change can and should be pre-calculated in advance.

Frying

This is the request time processing of data for the final presentation. Stylesheet assignment, session start/finish accounting, ad placements and other things that actually may change on a per request basis are handled by the HTTP delivery engine.

Obviously some applications (shopping carts, auctions, messaging, sports scores and stock quotes) are going to lean on the frying side. When a presentation is mostly of volitile data, the amount of baking will be minimal and crosses the street from web content to web application. This is not necessarily going to require different technologies but does necessitate a shift in computational burden. However, most web content doesn't change with a frequency that requires a web application server (apologies for raining on the application server vendors' parade).