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.