Site Pages vs Application Pages Explained & Customized vs Uncustomized

I will try to explain a bit about what the difference is between Site Pages and Application Pages.
There are some big differences, not only on the surface, but also under the hood.
I will explain it mostly from the WSS perspective, since this is what I haved used the most. I will not address publishing pages. I will also go into how code execution is handled.

Site Pages

Site pages are a type of page that can be customized by the site admins. This is not done through html markup, but by going to “Site Actions” and “Edit Page” on any Site Page (all default.aspx pages for instance). These pages can use all sorts of master pages for styling, and are most often visible to anyone unless it has been decided that it should not be the case.

There are 2 types of site pages: Basic pages and Web Part Pages.

Basic pages is a completely blank page when you edit it first. You will edit it using the build-in RichText Editor. This is a static page, and generally not used very much.

Web Part Pages are used a lot more (default.aspx) and when edited will show which WebParts are added, and you can add or remove Web Parts.
This is a more dynamic page since a lot of webparts gather data dynamically from lists etc.

The 2 states of Site Pages

Uncustomized Site Page

Before a site page is customized it is served to the users by compiling the page into an assembly DLL and loaded into memory. This single DLL can serve thousands and thousands of requests spread out over all uncustomized instances of the same page on all webs. This makes it very fast and preferred.
Uncostumized is the new proper term. They used to be called Ghosted. You can execute code on these pages, including controls, but it is not a good idea. See below for reason.

Customized Site Page

Once the site page is customized it can no longer be compiled directly from the file system.
The customized site page is copied in the content database (not moved, since some sites may still use the uncustomized verion), and must be read from there.
It negatively affects speed and scalability compared to uncostumized pages, but that is the price you have to pay to be able to easily make your own changes to the pages.
Custumized is the new proper term. They used to be called Unghosted.
These pages can’t execute code (Inline, Code-behind or controls. ). You can have an uncustomized site page with code that works, and you can deploy it to your customer without problems. The second the customer decides to customize the page, you will get in trouble, since the code will no longer execute (including controls). You will get an error. This can be bypassed as described later. I will explain later why this happends.

Application Pages

Application pages are the pages that are placed in the Layouts folder which is a subfolder to Templates (12\Templates\Layouts\). These pages are used for all sorts of administrative tasks. The dialogues you see when you create new sites, pages etc are all loaded from this folder.
Application pages normally uses the application.master masterpages. These pages arent very often styled since these pages are most often not seen by normal users.
Application pages are compiled into DLLs just like uncustomized site pages, and they can’t be customized. This type of page has no problems executing code. Both inline and code-behind will work, and also controls.

How Customized pages are parsed

It would be false to think that each customized page would be compiled into an assembly DLL. This would not be practical. A problem is that there really is a limit to the amount of DLLs you can load, mostly because of limited RAM om the system, but also there’s also a hard limit on amount of DLLs. Another problem with using DLLs for customized pages would be that once loaded into memory, you can’t just unload it as you like. The .NET Framework does not support it. You can recycle the process in Windows or the .NET AppDomain, but that would unload all the DLLs. That’s not really very good either.
What happends is that customized pages are parsed by the ASP.NET Page Parser and processed in no-compile mode.
It might seem slower to use uncompiled paged but with potentially many thousands of pages that should have been compiled into just as many DLLs, it makes sense.
The pages are parsed and once processed Control Trees are added to memory. SharePoint can unload the Control Trees once it’s done with them. No-compile parsing also skips the step of compiling into DLLs which is pretty time consuming. Actually this is usually what happends when you IISRESET a site and you wait for what seems like eternities before the page reloads.

When the page is Uncustomized this wait period doesn’t matter much, since one DLL can be served across a lot of sites, but on servers where there are thousands of small sites, odds are a lot of users would have to wait for the compiling pretty often. So No-compile gives faster response time, but for subsequent visits to the same page, it does not benefit from faster load times like pages served using DLLs.

How parsing of customized site pages affect code execution

As stated earlier you are able to execute code just fine on uncustomized site pages and application pages, but not on customized site pages. The reason is that customized pages are run in Safe Mode.
SharePoint is a but cautious of executing code on user created pages, since it is a real danger.
You can try yourself to make a site page and then add an inline piece of code or a custom control and access the page. Then customize the page and notice the difference that appears because of Safe Mode parsing.

This safe mode parsing can be bypassed (can’t figure out an example of a scenario where it would be needed though). This enables code execution. If you add AllowUnsafeControls=”True” on the PageParserPath it will also affect controls (You shouldn’t do that. You should add it to safecontrols instead)

In Web.config you can enter the following:


<safemode maxcontrols="200">
                CallStack="false" 
                DirectFileDependencies="10" 
                TotalFileDependencies="50" 
                AllowPageLevelTrace="false">
<pageparserpaths>
<pageparserpath virtualpath="/IT-Department/SitesPages/*">
                               IncludeSubFolders="True"
                               CompilationMode="Always"
                               AllowServerSideScripts="True" />
    </pageparserpath>
</pageparserpaths></safemode>

Controls can be added to safecontrols in web.config, and they will work. This enables you to mark individual controls as safe, unlike if you add the AllowUnsafeControls attribute.

<safecontrols>
    <safecontrol assembly="Code-Journey.Control, 4-part">
                      Namespace="CodeJourney"
                      TypeName="*" />
</safecontrol></safecontrols>

Summary

Site pages can be customized. Uncustomized site pages are compiled into a DLL during execution, and can be served swiftly to users once compiled. Once customized they are not compiled but are parsed using no-compile mode, and default policies makes it impossible to execute code on the pages (can be altered though). Moderate execution speed, since they are individually
Application pages does not support customization, and are always compiled into DLL during execution. Since they never run in no-compile mode, code can always be executed. They are placed in the Layouts folder.

Note: It IS possible to run codebehind on customized site pages, but generally explained as not. You can look at Andrew Connells site for details.