Ironically, dynamic websites are the least served by HTTP conditional GET, because by the time they've worked out whether or not a page's content is the same as what you've already got, they may well have generated the entire content. As a result, the only thing conditional GET really gets many dynamic websites is bandwidth savings, which may go some way to explaining why many dynamic frameworks don't have very good support for it.

(The same is true for HTTP HEAD requests, generally even more so. Fortunately they're quite rare.)

I think that what really hurts in this is templating languages. If you know the content structure going in to page generation, you can have basic elements with precomputed ETag hash values and so on, but flexible templates mean that you don't know the content structure until you evaluate the template to some degree. And the more power the templating language has, the more evaluation you need to do to know the content structure.

(The easiest implementation of ETag is to get the ETag value by hashing the page's more or less full text, which means that you have to generate most of the page's actual text before you can compute the value to check against the conditional GET's If-None-Match. Static file webservers get around this partly by making the ETag value out of easily gotten things like the inode stat() information.)

It's still useful to generate the HTTP headers necessary for conditional GET in your dynamic framework, since it preserves your ability to someday slap in a reverse cache in front of your actual dynamic bits. And once you're generating the headers, you might as well do actual conditional GET too; if nothing else you're saving your users some bandwidth and thus making your site snappier.