The problem with that approach is that you will never be able to personalize the results - or for example show a shopping cart to store selections, since your content is now static. Unless you have an ajax driven part.

From an engineering point of view, I would focus on providing functionality until I have a performance bottleneck - and at that point the correct approach is to cache some of the slow query results since the database usually consumes 90% of the script run time. Another approach is to speedup the database. Since the disk is what slows it down ( you can identify that by running atop ) the straight solution is to speed up disks - use RAID !

A third approach is to use faster storage engines, like BerkelyDB or derby instead of postgres or mysql. That would require more work on the code side, but will produce faster pages without changing the hardware.

If the CPU is a bottle neck then just cache some of the slow queries as I described earlier - however, you would really need a significant load with super fast RAIDs to reach that point.

So my school of thought is to continue using dynamic pages.

For updating listings, I compare the ModificationTimestamp in the Property search type. A similar time stamp exists with media.

So, do you write unique html pages every day, or do you only grab the homes that are updated? If so, which field do you use to scrub for homes that are updated?