Are SharePoint site templates really less efficient than site definitions?

Question

So, it seems in the SharePoint blogosphere that everybody just copies and pastes the same bullet points from other blogs. One bullet point I've seen is that SharePoint site templates are less efficient than site definitions because site definitions are stored on the file system. Is that true?

It seems odd that site templates would be less efficient. It's my understanding that all site content lives in a database, whether you use a site template or a site definition. A site template is applied once to the database, and from then on the site should not care if the content was created using a site template or not.

So, what is an architectural reason why a site template would be less efficient than a site definition?

---

Edit: Links to the blogs that say there is a performance difference:

• From MSDN: Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance.
• From DevX: However, user templates in SharePoint can lead to performance problems and may not be the best approach if you're trying to create a set of reusable templates for an entire organization.
• From IT Footprint: Because it is slow to store templates in and retrieve them from the database, site templates can result in slower performance. Templates in the database are compiled and executed every time a page is rendered.
• From Branding SharePoint:Custom site definitions hold the following advantages over custom templates:
  • Data is stored directly on the Web servers, so performance is typically better.

At a minimum, I think the above articles are incomplete, and I think several are misleading based on what I know of SharePoint's architecture.

I read another blog post that argued against the performance differences, but I can't find the link.

Answer 1

The performance impact of using Site Templates versus Site Definitions is generally overstated.

Why?

Well, lets take this example:

1. You take a Team Site site definition.
2. You save it as a new Site Template
3. You then create a new sub web based on this new site template.

What have you got? Well, the important thing to remember is that "Ghosting" happens at the PAGE level, NOT at the SITE level. Since you have not customised ANY pages, then any pages you access are still coming directly from the Site Definition, directly from the filesystem.

Want to prove it, here are two tests:

First Test

1. Try modifying the default.aspx page in the original Site Definition.
2. Check your site template, notice you see the modification.
3. Its still "Ghosted" to the filesystem

Second Test

1. Create a new site definition.
2. Create a new site based on this new Site Definition.
3. Create a new Site Template
4. Send the site template to a mate with SharePoint and ask them to create a new subweb based on it.

It will fail. Why? Because the Site Definition does not exist on their machine.

So, to get back to your question, "Are SharePoint site templates really less performant than site definitions?" my answer would be: "Performance considerations should not play a role in your decision to use a Site Definition or a Site Template, the functional objective you have should be". Now it get controversial, but for me, there are very very few reasons to opt for a Site Definition over creating Features.

As far as "Ghosting" goes. Yup, when customised your page will be stored in the Database, and yup, you will have to do a database round trip to get it. But, SharePoint, smart that it is, will of course cache this. So, in theory, yup its slower, in practice, no one really notices.

Ghosting has been in the product since 2003 (probably in STS before that, dont remember) and I have never seen official guidance on the performance impact it has, nor anyone speculating beyond the "it is slower" comments.

This leads me to believe that it just isn't really worrying about. The bigger worry with "Ghosted" pages is the difficulty that comes with maintaining them, but then, with 2007 and Masterpages this is a much smaller problem.

Answer 2

Site definitions are more performant because they are cached on the file system, whether templates are stored in the database and have to be compiled and executed every time a page is rendered. Also, custom site definitions are upgrade independent, unlike templates, that are based on an existing site template.

There are other differences nicely outlined in this blog post and this updated one.

Answer 3

The issue here is called Ghosting. An out of the box SharePoint site stores many files (including masterpages and pagelayouts) in the 12 hive of the SharePoint website. When a request is made for these files, SharePoint is smart enough to do a disk read operation.

It is possible to "Un-Ghost" these pages. Essentially, createing a modification to the page that is stored in the SharePoint conent database instead of the file system. A request for an Un-Ghosted page will result in a database round trip (selecting from the database, returning the bytes of the file etc). This necessarily results in a non-trivial amount of extra work. When you are talking about 100's or 1000's of users hitting the site, this database round trip becomes a performance issue.

So a SharePoint custom site definition for a heavily used website will want to store as many files on the web server file system as possible (and cache the .... out of everything else). A site definition is not necessarily stored on the file system, but the process (aside from being way more complex) gives far more control of the storage location of any customised items.

An example of two blogs talking about the issue. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614

Answer 4

The issue with unghosting is not as much a performance issue as an upgrade issue.

In SPS2003 unghosting had a performance drawback. Much of these problems was addressed in SharePoint 2007. For one thing, the un-ghosted pages run as no-compile pages by SPVirtualPathProvider -this actually gives a faster rendering at least for the first page.

The real killer with un-ghosting (or customizing -who ever thought it a good idea to both rename the term and also switch the "un"? ;-) is when you want to upgrade, and your pages, page layouts, master pages, content types etc are customized. If you ever tried doing a cosmetic upgrade of a MOSS site with extensive customization, you also know what a pain it is to get everything to show the new design, without loosing the layout or functionality contained in the customized pages.

hth Anders Rask