You’ll find these terms littered around posts and articles dealing with SharePoint content by the 1000’s. You’ll also see many an argument about whether Customized (Unghosted) content performs slower than Uncustomized (Ghosted) content.
What do they mean?
Easy, lets talk about SharePoint pages, in particular one we all know and love – default.aspx. Every time you create a site, there is always a default.aspx page in the root of the site and it acts as the site home page.
Now, we know that all content is stored in the content database right? Right! it does, and it doesn’t. That default.aspx page which comes from the site definition has a database entry, and assuming that that default.aspx page hasn’t been changed by anyone, the database entry simply refers (points) to some file on the hard disk filesystem (somewhere in the 12 hive) of the WFE server, which is the template of default.aspx. SharePoints virtual page parser, gets that file off the filesystem and hands it over to the ASP.NET processing pipeline, and from then onto the browser.
So far so good, in this scenario, the default.aspx page is known as Uncustomized (using WSS3 / MOSS 2007 terminology) or Ghosted (using WSS2 terminology).
Now, Bob comes along and changes the page using SharePoint Designer. At this point the page is different to the original template file as described by the site definition (and which is residing on the filesystem), and so SharePoint stores the page content itself in the database – the database entry for this page now doesn’t refer (point) to the template file on the filesystem (12 hive) – essentially default.aspx on this site has become decoupled from it’s site definition template, and is known as Customized (using WSS3 / MOSS 2007 terminology) or Unghosted (using WSS2 terminology).
For SharePoint to render this page now, the virtual page parser, gets the page content itself out of the content database and hands it over to the ASP.NET processing pipeline, and from then onto the browser.
Bear in mind that the content database may or may not be remote from the WFE server on which page rendering occurs, if it is remote, then obviously there will be some performance penalty for the WFE server to get a page content from a remote database, when compared to the page content being read directly from the filesystem on the WFE server itself.
If the content database is on the WFE server itself (single server deployment), in this scenario the difference will barely be measurable, and even less noticable. Obviously a remote content database server will be more the norm, certainly in Farm environments, so the question of the performance hit for Customized (Unghosted) content remains – I’m not even going to try and answer that one 🙂
But I hope this article has led you to understand the difference between these commonly used terms.
platinumdogs.me 
Very good article to understand the ghosting and unghosting terms used frequently in Sharepoint.
We have deployed a MOSS application in production server ( Multi server) and we are facing the the performanece Issue same as mentioned in this post.
Can any one provide me the solution to overcome with thi performacne penality.
Hi Vipin thanks
As far as I know, there is no solution, if you customize a page, its content will be stored in the Database.
If you can, you should try to package your customizations up into a feature and deploy them as Uncustomized (Ghosted) pages.
Hi Phil,
In my understanding the situation is a little more complicated then you describe. I believe when you simply add a webpart to a page it will not cause it to be “unghosted”, just a new webpartinstance-webpage association is recorded in the CDB. Unghosting only occurs when you open the page in SharePoint Designer, edit it, then save it. This is the moment where the page is decoupled from the template page and the new content is saved directly to the CDB.
Hi Andras, yes you are correct, I’ve updated the post accordingly
Hi Phil,
Thanks for the info. While I understand Ghosting and Unghosting, I’m wondering if you can reverse an Unghosted file, such as a master page. In a test environment, I’ve found that if I have a site with subsites that are all using my Custom Ghosted masterpage installed as a feature, but I then click Edit Page within Sharepoint Designer on the master page, it breaks Ghosting even if I don’t make any changes. Then, ALL of the subsites are now broken because they inherit that masterpage. Is there a way to change this back to being Ghosted?
If not, this could potentially be a big issue if someone accidentally Unghosted a top-level master page!
Thanks!
Paul
Paul, there is an option in SharePoint Designer to revert a file to it’s uncustomized state, IIRC if you right click the file you’ll find the option on the context menu.
Awesome!! Thanks Phil, can’t believe it was that simple!