Understanding Application Pages and Site Pages

Pages that support user customization are known as site pages. E.g. the page that we could see inside our SharePoint designer like default.aspx (home page), NewForm, EditForm,DispForm.aspx etc. The site pages could easily be customized without making any changes to the local file system of the front-end web server and without any need of developer involved for that. This is possible by storing the customized version of the aspx and master page files inside the content database. The saving and retrievig of content from the database is provided using SPVirutalPathProvider class. 

More on SPVirtualPathProvider


Site pages could exist either in customized(unghosted) or uncustomized(ghosted) state.

For e.g. when we create a new site using one of the default templates, the site as well as pages therin are in uncustomized state i.e. they are based on page templates that live on the file system of the front-end web server. Page template are used for provisioning (creating) page intances. As long as the page is not customized using SharePoint designer or through the Site Settings option the copy of the page is not stored in the content database and the pages are loaded from the file system of the web server. A single page template is compiled into an assembly and loaded into memory of IIS worker process one per web application.

However when page is customized, SPVirtualPathProvider retrieves the customized version of the page from the content database and passes it to ASP.NET parser. Now these pages aren’t compiled into assembly. They are processed by ASP.NET parser in no-compile mode.

No-comiple pages provide higher levels of scalability compared to compiled pages. Compiled pages offer following benefits

·         Performance   Compiled code is much faster than scripting languages such as ECMAScript or VBScript because it is a closer representation to machine code and does not require additional parsing.

·         Security   Compiled code is more difficult to reverse engineer than non-compiled source code because it lacks the readability and abstraction of a high-level language. Additionally, there are obfuscation tools that make compiled code even more resistant to reverse engineering.

However these compiled pages cannot be loaded into memory and unloaded in a manner similar to no-compile pages. .NET framework doesn’t support concept of unloading an assembly DLL from memory. By recycling the current Windows process or AppDomain it is possible to unload the dll, the issues is that it would unload all dll’s from memory, not any specific as desired. And moreover there is limit associated with number of assemblies that could be loaded in a .NET AppDomain.

With no compiled pages there is no requirement of loading assemblies into the memory. Processing for compiled pages is done by loading control trees into memory. Once the processing is finished for a customized page, the page’s control tree is unloaded to free up memory resources. And also as the pages are not compiled, it provides faster response time for pages upon first access.

No Compile Pages enables improved scaling for large sites with 1000s of pages, as windows has limit on number of DLLs loaded into an app and perf degrades as you hit this limit.

Application pages are pages that don’t support customization. They cannot be customized using SharePoint designer. E.g. settings.aspx, create.aspx etc.

These pages are deployed at \Layouts directory of 12 hive and are available to all the sites. They are compiled into a single dll and loaded into memory once per web application. They are used extensively for provisioning and administrating sites as well as elements inside the sites. Application pages links to application.master.

So main differences between these two types of pages could be summarized as  

1)      Site pages support customization whereas application pages don’t.

2)      Site pages once customized run in no-compile mode whereas application pages are always compiled.

3)      Now as site pages support customization it involves risk so under default security policy enforced by WSS we couldn’t write inline code in it  whereas it is allowed to write in-line code in case of application page.

4)      Application page scale better than site page. 



Author: Nishant Rana

I love working in and sharing everything about Microsoft.NET technology !

5 thoughts on “Understanding Application Pages and Site Pages”

Please share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Sharing my knowledge and experience about the Microsoft Power Platform.

Arpit Power Guide

a guide to powering up community

Welcome to the Blog & Website of Paul Andrew

Technical Leadership Centred Around the Microsoft Data Platform

Deriving Dynamics 365

Deriving Solutions and features on Power Platform/Dynamics 365

The CRM Ninja

Thoughts & musings from a Dynamics 365 Ninja!

D CRM Explorer

Learn about Microsoft Dynamics CRM Power Platform customization and implementation and other cool stuffs

Stroke // Jonas Rapp

I know pre-stroke. I will improve who I was.

Power Melange

Power Melange By Shalinee

Clavin's Blog

Power Automate - Power Apps - SharePoint Online - Azure - Nintex - K2 - Artificial Intelligence

Sat Sangha Salon

An Inquiry in Being

The Indoencers

The Influencers & Influences of Indian Music

Monika Halan's blog

Hand's-free money management

D365 Demystified

A closer look at Microsoft Dynamics 365.

Microsoft Mate (msftmate) - Andrew Rogers

Experienced consultant primarily focused on Microsoft Dynamics 365 and the Power Platform


Specific topics by Django Lohn on the whole Microsoft365 Stack

Manmit Rahevar's Blog

One Stop Destination for Microsoft Technology Solutions


Naturally Curious

Brian Illand

Power Platform and Dynamics 365

Steve Mordue MVP

A Microsoft Business Applications MVP

Subwoofer 101

Bass defines your home theater

SQLTwins by Nakul Vachhrajani

SQL Server tips and experiences dedicated to my twin daughters.

Everything D365

Discovering Azure DevOps and D365 Business Applications

Tech Wizard

Lets do IT Spells

XRM Tricks (Power Platform & Dynamics CRM )

Power Platform & Dynamics CRM


Mail to crmtipsbyprm@gmail.com for queries and suggestions


Giving back to the community what I have learned

xrm CRM Dynamics

Dynamics CRM Technical & Functional Info

Dynamics 365 Blogs - Explained in unique way

Sometimes you need to look at things from different perspective.

CRM Keeper

Dynamics 365 Customer Engagement, CRM, Microsoft CRM, Dynamics CRM


Step into the world of a Dynamics 365 Consultant

Dianamics PCF Lady

Diana & Dynamics 365 & Power Platform

Sara Lagerquist

No Code Customization Concepts

%d bloggers like this: