<Disclaimer>This is personal notes of what I retained during the session. This can be incomplete, partially right or wrong. It is just  part of the notes I took and what retained my attention. Nothing prevents the user to get more information on their favorite web site.</Disclaimer>

Andrew Connell, MOSS MVP, starts by exposing some of the actual problems we can encounter when deploying a MOSS publishing site. First, when browsing such site, IE displays a warning message saying that the Name ActiveX must be trusted and installed on the client machine in order to see the web site, which is really not ideal. For that, there is a workaround explained in the MS KB 931509.
The second problem is how to minimize the page payload due, mainly to the table layout used in SharePoint. A first recommendation would be to use a CSS based design. It will be even more efficient because the CSS files are cached. Then, enabling the HTTP compression reduces by 71% the amount of data transfered. And finally, on a standard SharePoint page, Andrew showed us that 26% of the payload is used to transfer the core.js file (54K), which is used only for the Site Actions menu. The branding and content consumes more or less 45% of the payload, while the other scripts and CSS files 29%. The problem is that core.js is not used for internet facing applications, but if it is suppressed, we are in a non MS supported scenario. So, rather than putting core.js at the top of the master page, it is better to load it asynchronously. To do that, it is necessary to implement the OnInit event in a custom control that will download the core.js on the client side only if the access is anonymous. Then, at the bottom of the master page, an IFrame is placed with the load of the core.js file.
One of the biggest issue with custom control development is that they don’t work with the WSS_Minimal security policy. So, there are two choices : increase trust to WSS_Medium or event Full, or to increase the trust of the custom components in the CAS.
Moreover, the /pages/forms/allitems.aspx is, by default, accessible to all users, which is not really good for publishing sites. The problem comes from the fact that the access is granted by the “Limited Access”. To solve this problem, the ViewFromPagesLockdown feature that removes this right needs to be activated or reactivated if needed.
Page Output Cache is not activated by default. Enabling it will allow the generated HTML to be stored in RAM. Specific profiles can be created to apply to specific sites.
Object Cache allows to store objects coming from the database in RAM. The amount of memory is configuratble (default to 100MB). To check the effectiveness of the object cache it is possible to use the ASP.NET 2 Performance Counter Cache Hit Ratio. If it is less than 90%, increase the configured memory.
Disk Based Cache is used to save roundtrips to the database for content with a consequence that content will be stored on the WFEs disk. It is configured in the web.config file, unders the <BlocCache> element.
On the topology side, it is strongly recommended to use different environment for authoring and for production and also to use the Web Content Management content deployment features to migrate content from one environment to the other. In order to optimize the environments, set the authoring environments rights to read/write while in production, set it to read-only.