Geoffrey,

regarding DotNetNuke performance, there are several use cases you have to distinct:

1. initial page load, after the site has not been accessed for some time (by default 20 mins)
2. load time of first page, when a user visits your site the first time
3. view of subsequent pages
4. view of pages, when logged in

 performance is relying on a number of factors, for DotNetNuke and the cases stated before this is (besides underlying server hardware, especially RAM size, and connection speed):

1. on initial load, ASP.Net sites need to get JIT compiled. This is not a big issue, because the result gets cached, however, by default IIS application pools are configure to recycle after 20 minutes of inactivity and need a recompile, when the site is accessed again for the first time. This can be prevented by a ping service like the one from PowerDNN, however, if you have control over the web server, it is preferable not to recycle the process after inactivity and only, when RAM is low and usually once per night.
2. on first access of a user, he needs to download ALL items, i.e. all images, CSS files and Scripts. To improve load time, scripts and CSS files should be reduced (besides all actions taken for 3.), but there are limits if you are using a CMS like DotNetNuke. Compression shall be turned on to reduce amount of data to be transmitted and will help a bit, but by default, CSS and Script files are not compressed. Compression and caching tools like PageBlaster may improve performance, but IMHO you should have some knowledge about IIS in this area before using it.
3. Depending on the browser settings of the user, most of these files get cached on the client, and only new files (usually HTML and images) get downloaded on subsequent pages. Reducing size of images and HTML is the main option you have to reduce size and the number and type of modules used plays a major role, since modules not only download the HTML displayed but often an additional amount of data for the controls, called v13wstat3. There is an option in host settings to store v13wstat3 in memory on the server, but AFAIK this is not very reliable and requires a lot of memory, if you have a number of concurrent users.
   The second part to optimize is the time to "produce" the page, before it gets downloaded onto the client. This is, where caching comes to play. Object caching reduces the number of time costly calls to the database and module caching stores the module output (for unauthenticated users only), which doesn't need to be regenerated for subsequent users, as long as its cache duration.
4. There is no module output caching for authenticated users, this is, why those will usually have decreased performance (depending on the modules and its use of object caching).

What was the "muddle" on the PageBlaster site?

The default configuration of PageBlaster is very straight forward and does not require any user intervention at all.  After installation you should see a noticeable improvement on all pages after they are accessed the first time.

Sebastian raises some good points.  Any page can be continually tweaked/optimized for better performance, but PageBlaster does a very good job of doing a lot of the work automatically.