Jason Salas' WebLog

aspx pages are actually "first time compiled" into an asp.net controlled area.

when you move the site, you typically wont move those with the app, since the pre-compiled page dll's are in a totally different area.

in theory, another server with faster disk i/o could make the actual compilation process very short, almost illegible to the end user (obviously a good situation)

the initial default.aspx startup probably was long because maybe iis hadn't spun up, the iis application process hadn't spun up, and finally aspnet handler hadnt spun up, so then once all that mess is in memory it was probably blazing fast, and given the potential with xeon processor's huge memory cache, might have brought all that into its cache...

just fyi. note that asp.net 2.0's compilation is very similar now. The "precompiler" simply makes simulated requests against all the aspx pages. One nice feature of the precompiler is having it precompile it all into one dll, which may or may not be good for sites that change their aspx pages often.

ironically, i've been wondering if an interpreting handler (think classic asp where each page was interpreted at runtime) for sites that build a lot of aspx pages, like content management and so forth, would be better in the sense to ease memory pressure in the form of the "compiled aspx" types... since you can't unload dlls without unloading the appdomain, a site like codeproject that basically "writes an asp" for each article (assuming they dont have an isapi filter that rewrites the path), then you wont have, say codeproject has 300,000 articles, then they wouldn't have that many "compiled aspx" types in memory... some food for thought ;-)

The pages get compiled to one assembly per folder under your web app. Here's an interesting article that talks more about it: http://aspnetresources.com/articles/debug_code_in_production.aspx

Jason, startup time for the first page is always a tricky one, because there may be a lot of things starting up at the same time. 20 seocnds is pretty slow but it obviously depends on the type of machine and load on the box. Worst case scenario is IIS was just started and you hit an ASPX on the first hit. So you have IIS starting, then starting an Application Pool worker Process (or ASPNET_WP in IIS5), you have .NET loading into it, then the default AppDomain is created, then another AppDomain for your ASP.NET application, then the default page is compiled which in turn pulls in a bunch of other referenced assemblies for the first time as well as the code behind assembly.

A lot is happening on that very first request.

Then again, hitting a freshly started IIS site even with a static page isn't exactly blazingly fast either... I'd say the biggest hit is the .NET runtime loading into the worker process.