In wss3, cutomized pages are not processed by using the standard ASP.NET mode in which a page is compiled into an assembly, instead, customized pages are parsed by the ASP.NET page parser and then processed using the no-compiled mode feature that was instoduced with asp.net 2.0.
Why customized pages are processed in non-compile mode? Although compiled pages run faster than non-compile pages. However, no-compile pages can be more efficient and more scalable in certain scenarios. This is ture in a large WSS enviroment where the number of customized pages can reach into the thousands or tens of thousands. No-compile pages can be loaded into memory and then unloaded in a memner that is not possible for comiled pages because the .net framework doesn't really support the concept of unloading an assembly dll from memory. The closes equivalent would be recycle the current windows process or .net appdomain. Howevery, this type of recycling involves unloading all assembly dlls from the memory, not just those assebly dlls that haven't been used recently. Futhurmore, the .net Framework places an upper limit on the number of assembly dlls that can be loaded into a .net appdomain.
No-compile pages provide higher levles of scalability because they do not require loading new assembly dlls or managed classes into memory. Instead, the processing of no-complie pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficently because they are not compiled into assembly dlls. For example, once wss has finished processing a customized page, it can unload the page's control tree to free up memory for other purpose. Furthermore, noncompile pages eliminate the need to go throuhg the compilation process, which actually provides faster response time for pages unpon first access.