SharePoint Site Template Vs Site definition

There is always some confusion on when to use site template or site definition. I found a nice explanation to this confusion on MSDN2.  According to the article;

“When to Use Site Definitions

Customizing portal sites and other SharePoint sites using site definitions is most appropriate for third-party developers and server administrators. Because site definitions require access to the file systems of the Web server, server administrators must always be involved in the deployment of site definitions. If you are modifying areas of a portal site, then you will need to use site definitions.

Although deploying a site definition requires more work, site definitions typically perform better when cached on the file system instead of in the database. In addition, you can achieve a finer level of customization by directly editing all the schema files and not depending on the existing site definition as a site template does. Also, if you want to introduce new file types, view styles, and drop-down edit menus, you need to edit the schema files that make up the site definition.

Custom site definitions are version and upgrade independent. Subsequent upgrades to SharePoint Products and Technologies may overwrite existing default site definitions. Using custom site definitions excludes your sites from potential upgrade issues.

However, there is no easy way to modify site definitions once they are deployed. There is always the possibility of breaking existing deployed sites derived from the site definition once you modify an existing site definition. You can only add to the site definition once it is deployed.

When to Use Site Templates

Site templates, compared to site definitions, are easy to create and deploy. You can make all customizations through the user interface or FrontPage 2003. In addition, you do not need to be a server administrator on the Web server to create and deploy site templates. You can modify a site template without affecting existing sites created by the template. Deployment is simple because template data is stored centrally in the configuration database.

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. Windows SharePoint Services does some performance optimization whereby it stores templates on the local Web server and a copy (or “ghost”) of the page in the configuration database. However, you can easily prevent Windows SharePoint Services from using a copy of the page by using Web Folders or FrontPage to open, modify, and save it. From this point forward, the database is used to render the page. Preventing Windows SharePoint Services from using a copy of a site page will cause the page to stop picking up changes from the site definition files, so if you want to keep a consistent look across the entire portal and only want to modify the site definition files, then don’t prevent this optimization. Rendering pages from the database will result in an initial performance penalty.

Site templates only work on SharePoint sites that are not portal sites (not based on the SPS templates). Furthermore, site templates are not ideally suited for a development environment. In effect, they are still customizations of a site definition. If the site definition does not exist on the server, the site template fails.

Typically, because of these issues, site templates are not as efficient as site definitions in a large-scale environment”

But you should notice that, when you create site out of site template or site definition, and make changes to either of them, will that effect the sites already created out of them? I am still having this confusion.

---

Possibly related posts: (automatically generated)

• Site Templates Vs Site Definitions – Part 2
• Size Limitation on Sharepoint site templates.
• Create a SharePoint Site Quota Template
• How To add Site Template Like Site Definition and ready to use for webappli…