Building public facing websites on SharePoint 2013 – Part 1

Yesterday I had the great opportunity to present at the Perth leg of SharePoint Saturday for 2013. Overall the event was a resounding success – the turnout was reasonable considering it was the day of the state election and while the numbers may have fluctuated across the entire day, a number of sessions were well attended in all of the time slots. I had roughly 25 in my session which didn’t reach the great heights of my user group session on Harnessing Client-Side Technologies to Enhance your SharePoint Site however seemed a decent turnout considering there were 2 other quality sessions on at the same time and the overall numbers would have been less than the many which attend the monthly UG sessions.

After having some success with my previous session linked above I decided to follow the same presentation format – half an hour dedicated to slides and theory and another half hour dedicated to demonstrations. At the end of the day I probably whipped through the slides a little quicker than I expected which guaranteed I had enough time to finish off the 4 demo’s I had hoped to get through.

This post will run through the background to each slide shown below, then part 2 will give a run through of the steps and comments associated with each demonstration performed.

Building public facing websites on SharePoint 2013

The cover slide gave me an opportunity to thank everyone for supporting SharePoint Saturday in Perth and particularly choosing my session for the time slot – it’s definitely something I appreciate and is worth repeating in this post. I covered off a little bit about myself and explained my public facing website journey on SharePoint starting at Tourism on the now infamous westernaustralia.com website and various partner sites to my more recent experiences at the Department of Training and Workforce Development on various departmental and TAFE institution web sites – the most recent being developed on SharePoint 2013.

Agenda

There were 2 main things I wanted to get out of my session – firstly I wanted to generate some excitement on the possibilities that existed around building public facing websites on SharePoint 2013 but also transfer some knowledge around the key areas which are often neglected when building an internet facing site. I wanted to cover off how each version of the platform performed in each area then explore the new and exciting features which exist for web content management on SharePoint 2013, backed up by a number of demonstrations on my favourite features.

Branding & UX

Most people think branding SharePoint is all about slicing and dicing images into Master Pages and Page Layouts – and while this is a large part of it, there are a number of other factors which should be considered for a successful site. Implementing Custom Error Pages is one factor which is often forgotten about and can make the difference between your site looking professional or incomplete. The client-side and search experience is another area which can transform your site from something which looks good to something which performs great.

Search Engine Optimisation

SEO is often neglected or considered as an afterthought once the website has already gone live and traffic is not up to expectations – it is a crucial factor to consider to maximise the number of visitors to your public facing site. The topic is worthy enough of a presentation of its own however I have a 3-part blog series on Search Engine Optimisation for SharePoint Sites and Ian McNeice has written a great global SEO strategy book which cover the details. The main takeaway from this slide was that effective SEO requires a 3-phased approach – identify the keywords and phrases which are most effective to optimise for, optimise your site for those keywords and phrases and finally think outside the box for ways in which you can drive traffic to your site – rating well in the search engines in merely one component to an overall strategy.

Performance Optimisation

If SEO is all about bringing people to your site then Performance Optimisation is all about keeping them there. There are some great statistics and studies on the web which link bounce rates to page performance so it is most definitely an important factor to consider when building a site. There is a common misperception that SharePoint is inherently slow but that’s not a theory I subscribe to – a poorly developed and optimised site will perform badly on any platform – it’s just that SharePoint is easy to blame. Again this is another area in which an entire presentation could be dedicated and while I have another 3-part series on Performance Optimising SharePoint Sites the main takeaway was that while there are a number of generic and SharePoint-specific tasks you can target to optimise a site, there are also a number of great free tools available to benchmark and measure the performance of your pages including webpagetest.org, ySlow and Google Page Speed.

Accessibility

From a couple of topics which are often neglected or postponed to one which is often discarded completely. While it’s understandable how accessibility sometimes falls by the wayside due to its at-times difficult and time consuming implementation on SharePoint it’s interesting to note the time often dedicated to cross-browser compatibility for browsers with a lower percentage of use compared to the numbers that would benefit from an accessible site. This is particularly important for WA Government Organisations who have a mandate to ensure all websites are WCAG 2.0 compliant by the end of 2013. Vision Australia has written a great whitepaper on Achieving Accessibility in SharePoint 2010 which should be read for more information.

SharePoint 2007

So how does each version of SharePoint fare in these areas? Before I start it’s important to point out that any discussion on Licensing is generic and ballpark – I’m no licensing expert and the numbers have been taken in US dollars and at the time they were relevant – see the hyperlinks for the source.

Licensing: MOSS was fairly expensive to host public facing sites. At roughly 40k per internet server plus external connector licenses and with best practice guidance recommending a staging server with content deployment to production you can quickly see how even with a small web farm of 2 front end web servers and an application server how costs would add up.

Branding: Nothing to write home about here – we had ASP.NET 2.0 Master Pages and Page Layouts but that’s about it. Guidance was low in the early days, the starter master pages had yet to become mainstream. Custom Error Pages (other than 404) were particularly difficult to implement. jQuery had yet to take hold which left us with the AJAX toolkit and UpdatePanels which unfortunately required a number of manual web.config modifications to get working. MOSS for internet sites required an enterprise license, so at least we had enterprise search.

SEO: Practically non-existent. Even targeting the most basic of generic techniques generally required custom development.

Accessibility: If SEO was bad then accessibility was worse. View source of a MOSS-hosted site and you’ll see table hell – I pity anyone who had the task of getting MOSS 2007 accessible.

SharePoint 2010

Things were a little better in 2010, this is generally how it measured up:

Licensing: While we were no worse of in 2010, we weren’t really much better off either. Enterprise internet servers were still around the 40k ballpark although the external connectors were a bit cheaper. We did have the ability to purchase Standard licenses for internet sites which would be about 25% of the price – however there were a few caveats which often meant this wasn’t feasible, particularly the inability to host multiple domains on the server.

Branding: The Master Page and Page Layout story was the same, however there was far more information available plus the starter master pages had become widely used. jQuery had taken off and there were a number of blog posts regarding how to include it in SharePoint and a number of plugins which could be leveraged, and if you were still stuck with the AJAX toolkit then at least it was supported out of the box. We had the option of using FAST search for internet sites (for an additional license cost) which gave some flexibility around search. The custom error page story was much better – far easier to implement across the board compared to SharePoint 2007.

SEO: Unfortunately much the same – custom development was still required.

Accessibility: Thankfully much better – SharePoint 2010 launched with the goal to being WCAG 2.0 AA compliant and while it didn’t quite get there, the HTML rendered was much cleaner (aside from the tables generated by web part zones) and there was guidance around making 2010 completely compliant via the whitepaper I’ve mentioned above.

SharePoint 2013

Definitely the best of the bunch which is no surprise considering I dedicated an entire presentation to it.

Licensing: While there may be no official licensing details available, a number of sources suggest that the licensing for 2013 will be far more affordable. No longer do we need internet server licenses – an enterprise license with internal CALs will suffice. FAST search is now also inbuilt rather than being an additional licensing requirement.

Branding: Has changed completely in 2013. While we can still use the tried and true method of Master Pages and Page Layouts in our VS solutions, we now have the Design Manager which puts the power into the Designer’s hand and removes the need to have SharePoint developers implementing branding. There is also webdav support to connect to the master page gallery directly with an ability to edit linked HTML files which will automatically update the associated master page. A custom 404 page is provisioned and editable straight out of the box in 2013 and the other error pages are just as easy to implement as 2010.

SEO: Finally the platform has treated SEO with the respect it deserves – a number of generic SEO requirements being available straight out of the box.

Accessibility: The HTML markup is cleaner again, web part zones no longer rendering out tables. I’m unsure if 2013 is completely WCAG 2.0 compliant however if it is not, it would definitely take less effort to ensure that it was.

New Features for WCM in SP2013

A large number of new features exist for web content management in SharePoint 2013 however these are the ones I believe will be the most useful for building public facing sites.

Pasting content directly from word: Previously the experience of pasting content directly from word was a painful one – embedded styles would remain and cause certain pages to look completely different from the rest of the site’s style. This new ability will remove the need to use notepad as a go-between when pasting content from word to SharePoint.

Image renditions: This feature is getting a lot of airplay currently over the web and for good reason – it’s a great new feature. Essentially allowing you to upload one larger image and create different ‘renditions’ of the image at different dimensions, this feature will be great for mobile versions of websites which will allow a smaller file-sized image to be downloaded for rendering. Requires the BLOB cache to be enabled.

Cross-site publishing: Another highly useful feature in SP2013. Allows content to be published from one site collection to another. Many practical uses include separating editing/publishing environments, variations and particularly relevant for myself and government departments who host multiple sites – being able to share content between them while maintaining the individual branding of each department’s site.

Managed navigation / friendly URLs: My favourite feature of the lot – managed navigation is a step away from the structured navigation we’ve grown accustomed to. Allows you to define a taxonomy hierarchy which will drive navigation. Most importantly it allows you to implement friendly URLs which users have been crying out for for some time but also allows you to decouple structure from navigation ensuring you no longer have to create numerous sub-sites just to position a particular page at a given URL.

Search driven content: Used significantly for the purposes of cross-site publishing, it also has other uses including amalgamating content. Similar in theory to the content query web part however uses search as its content source – necessary if you want your friendly URLs to be rendered via the query. The best part is that XSL is no longer required to style the output – we can now use HTML and JavaScript via Display Templates.

Design Manager + Device-specific targeting: While I mentioned the Design Manager previously, another great feature is device-specific targeting. This allows you to use the same pages and content but recognise the device accessing it so you can use different master pages and styles to render that content – highly valuable for mobile sites.

SEO features: Some search engine optimisation techniques are now available out of the box which is fantastic news for those building public facing websites on SharePoint 2013.

WCM Feature Demos

Refer to Building public facing websites on SharePoint 2013 – Part 2 for a run through of the demonstrations which were performed in this session and some of the comments surrounding them.

Questions? Comments? More info..

While no questions were asked on the day it probably had as much to do with the session running its full hour and lunch having already been served rather than the presentation being so comprehensive that no questions were necessary! If anyone has any questions or comments feel free to leave them on this post or get in touch with me directly.

Thanks for listening

And thanks for reading! It was a pleasure being able to present this session on such a great day at such a well organised event, Brian Farnhill and the team did a great job putting everything together, the sponsors came on board to offer a great venue, food and prizes for the day and I look forward to being a part of it sometime again in the future.

Performance Optimising SharePoint Sites – Part 3

In Performance Optimising SharePoint Sites – Part 1 of this series I focussed on some of the first steps you should undertake or consider when embarking on performance optimising your SharePoint site. Performance Optimising SharePoint Sites – Part 2 explored some of the platform-independent techniques available at your disposal while this part of the series will identify some of the SharePoint-specific techniques able to be leveraged.

This is another topic where the information available is quite extensive. In a lot of cases however the information is either spread around or quite targetted so I think there is some value consolidating a lot of these ideas as part of this series.

One aspect of performance optimisation for SharePoint sites I won’t delve heavily into is on the infrastructure and administration side. This isn’t particularly my area of expertise so instead i’ll invite you to read some articles with more appropriate authors including Arpan Shah’s Things to Consider for SharePoint Performance, David Lozzi’s Improving SharePoint’s Performance and Eric Shupps’ 10 steps to optimize SharePoint performance.

Make sure your Objects are Disposed Correctly

It could be considered that this has been done to death and surely no one out there would fall into the trap of incorrectly, or failing to completely, dispose their SharePoint objects – but no performance optimisation article would be complete without at least mentioning it. It’s one of the most serious pitfalls a developer can fall into when developing a SharePoint site. Two main resources exist to steer you clear of this evil; the MSDN articles Disposing Objects for SharePoint 2010 and Best Practices: Using Disposable Windows SharePoint Services Objects for SharePoint 2007 and the SPDisposeCheck tool which can be run over your code to check for potential errors. There really is no excuse to letting these issues slip through the cracks and should definitely form part of your optimisation process.

Perform a Code Review and Ensure Your SharePoint Code is Optimal

Aside from object disposal mentioned above, a number of other code factors exist which can leave your pages rendering in a less than optimal time. A number of blog posts run through a bunch of these including Andreas Grabner’s How to avoid the Top 5 SharePoint Performance Mistakes, Eric Shupps’ SharePoint.Performance: Optimizing Web Parts and Waldek Mastykarz’s Performance of various methods to retrieve one list item. However the best resource i’ve found in regards to writing optimal code is on the MSDN site Developer Best Practices Resource Center – definitely worth your time in parsing through all the information on that site to ensure your code is as optimal as it can be.

Use Caching within your Code

No matter how optimal you eventually make your code, it will still be slower than not having to query the information in the first place. Caching is a great mechanism to allow you to run the query once then retrieve the data from memory on subsequent loads. There’s always a trade off between caching the data for performance and the currency of data – the trick is to find the balance between improving the performance of your site and ensuring the data being displayed is relatively up to date – this could differ on a case by case basis. You can either harness the built-in SharePoint objects which handle the caching for you or cache the objects yourself. Claudio Brotto has a good article on all things caching at SharePoint Internet Sites – Performance Optimization for Data Access which is worth a read.

Make Use of SharePoint’s Built-In Caching Functionality

SharePoint also has other built-in forms of caching that can be harnessed for your site both identified in Claudio’s article above; the Output Cache and the BLOB Cache. There are pitfalls associated with caching and these need to be considered, however caching is one of the most powerful methods of improving the load time of your SharePoint site. For more information on BLOB caching i’d recommend reading Sean McDonough’s Do You Know What’s Going to Happen When You Enable the SharePoint BLOB Cache? – it’s a long but quality post. For Output Caching (and caching in general) have a read of Tobias Zimmergren’s Caching in SharePoint 2010. As a side note particularly for SharePoint 2007 you may need to consider the issues Chris O’Brien identifies in his article Optimization, BLOB caching and HTTP 304s.

Get Rid of those Unnecessary SharePoint JavaScript Files

If your site has been extended to solely be an anonymous internet site then chances are a bunch of JavaScript is being downloaded to the page that will never be used by the end user and you should strongly consider changing that. Microsoft covered this off in SharePoint 2007 in a section (within a larger article) titled Managing Page Payload (Small Is Good). Chris O’Brien covered this off again in SharePoint 2010 in his post Eliminating large JS files to optimize SharePoint 2010 internet sites and Mahmood Hamed extended on that in his article Eliminate large JS files to optimize SharePoint 2010 internet sites: the complete reference.

Consider Warming up your SharePoint Site

Warming up the pages across your SharePoint site is a good idea for two reasons. Firstly, ASP.NET’s Just-In-Time compiler will often cause the first access of a site to be extremely slow compared to usual. Secondly, the caching techniques discussed previously only kick in once a page has been visited for the first time. By running a script or job to warm up the site you can avoid the ‘first hit’ performance lag associated with these issues. There are a number of sources of information regarding this topic but one such article that seems to collate a lot of them is Wahid Saleemi’s Roundup: SharePoint Warm-Up Scripts.

So that about sums it up – my take on a start to finish process on performance optimising a SharePoint site. When approaching this task with limited time and budget it’s important to target the factors you believe will offer the greatest gain for the time required to implement. With any luck the tasks completed will be identifiably successful enough that future projects will be undertaken with performance in mind right from the start.

Performance Optimising SharePoint Sites – Part 2

In Performance Optimising SharePoint Sites – Part 1 of this series I focussed on some of the first steps you should undertake or consider when embarking on performance optimising your SharePoint site. This part of the series will explore some of the platform-independent techniques available at your disposal while Performance Optimising SharePoint Sites – Part 3 will identify some of the SharePoint-specific techniques able to be leveraged.

Before I delve into some of the techniques available I should point out that the information available on this subject is extensive. It may seem a bit redundant even including this section in my series due to the wealth of information available elsewhere however I’ve done so for completeness. Both Google and Yahoo offer terrific sources of information on this subject matter if you’d prefer to go directly to the source – i’ll try to differentiate my contribution by linking to alternate tools and resources.

Minimise HTTP Requests

Reducing the number of HTTP requests on your page is one of the best ways to reduce the load time, particularly for first time visitors. As pointed out on Yahoo’s performance rules page via Tenni Theurer’s Browser Cache Usage – Exposed! 40-60% of daily visitors to your site come in with an empty cache. Every request requires a round trip to the server so it’s easy to see how this component of page optimisation could provide a significant improvement to the overall load time of the page. The majority of techniques that can be used to achieve this will be identified in the following 3 sections.

Optimise your JavaScript

There are a number of ways in which the JavaScript on your site can be performance optimised. Firstly, you should Move Scripts to the Bottom as Steve Sauders explains. This enables progressive rendering and helps to achieve parallel downloads. This should only be done where it doesn’t impact the visual rendering of the page. You should ensure that JavaScript isn’t duplicated within your site – either in various libraries or particularly in terms of referencing the same file multiple times (which can happen if you’ve included the reference in multiple web parts or controls). Your JavaScript should exist in external files rather than inline so that it can be cached and hence not add to the size of the HTML document. You should combine your JavaScript into as few external files as possible to minimise the number of HTTP requests and finally you should minify those external JavaScript files. There are a number of resources available to assist you in automating the minification process, both for Visual Studio described in Dave Ward’s post Automatically minify and combine JavaScript in Visual Studio or if you prefer it with a SharePoint flavour via Waldek Mastykarz’s Minifying JavaScript and CSS files made easy with Mavention SharePoint Assets Minifier.

Optimise your CSS

Similarly to optimising JavaScript, you can perform a number of optimisations to your CSS. Whereas you should load your JavaScript at the bottom of the page to enable progressive rendering, with CSS you should Put Stylesheets at the Top. You should always refactor your CSS similar to how you would your code to ensure it is optimal and doesn’t repeat definitions. Take advantage of the fact you can assign multiple classes to your elements – for instance where appropriate include a base CSS class which has the shared definitions and another which has the unique ones. You should externalise your CSS for the same reasons as you should your JavaScript and combine your CSS into as few external files as appropriate (find the balance between reducing HTTP requests and combining a large amount of CSS which is only used on one or two pages). Finally, you are also able to minify your CSS much in the same fashion as you can your JavaScript.

Optimise your Images

Along with HTTP requests, the size of images is one of the biggest factors in determining page load times. There are 3 major areas of focus when it comes to optimising your images. Firstly, it is important that the images are as optimised as possible to begin with. This means achieving smaller file sizes without reducing the quality of the image itself. A number of tools exist to assist with this highlighted in Jacob Gube’s post 8 Excellent Tools for Optimizing Your Images – the one I’m most familiar with it Yahoo’s Smush.it. Secondly, it’s important to ensure that you’re not relying on the browser to resize your images. It is common to find large images reduced in size by the size of the containing element which is definitely not optimal. Finally, CSS sprites can be used to reduce the number of HTTP requests required to retrieve the images explained via Chris Coyier’s CSS Sprites: What They Are, Why They’re Cool, and How To Use Them. One thing you’ll want to consider is that you may be able to optimise the images for the site initially, but if you have content being added by end users and they upload and reference unoptimised and HTML-resized images to a page you’re at risk of losing the optimised nature of that page. One final thing to note is that if you’re displaying a page with a known transition path you can pre-load the images that will appear on the next screen/page to further optimise that page’s load time using a method such as CSS Ninja’s Even better image preloading with CSS2.

Utilise GZip Compression

GZip compression is another way in which you can reduce the size of the payload coming back from the server to the user accessing your site. The majority of browsers support GZip compression and hence this should not be ignored. For a better explanation of why it is beneficial and what it actually does have a read of Kalid Azad’s How To Optimize Your Site With GZIP Compression. For implementation details with IIS6 see Bill Baer’s HTTP Compression, Internet Information Services 6.0, and SharePoint Products and Technologies or Todd Sharp’s Enabling GZip Encoding On IIS7.

In Performance Optimising SharePoint Sites – Part 3 of this series i’ll identify some of the SharePoint-specific techniques able to be leveraged.

Performance Optimising SharePoint Sites – Part 1

For anyone involved in delivering public facing websites, particularly for an international audience, minimising page load times would have to be something high on the agenda. While this subject is not limited to sites hosted on SharePoint, it is an essential topic for consideration for any SharePoint project. There is somewhat of a misperception that SharePoint is inherently slow and often becomes the primary target of blame when trying to work out why page load times aren’t to an acceptable standard. The simple fact is there are a number of optimisation techniques available to be leveraged to minimise page load times.

These topics are not only relevant to public facing websites – a number of them are applicable to intranets and extranets experiencing performance issues. My personal experience in this field stems from delivering a number of public facing websites to specific performance targets. My initial exposure to optimising SharePoint sites came working with the team at Tourism WA on the famous SharePoint site westernaustralia.com and most recently in the early stages of a site optimisation phase for the Career Centre website.

Ideally site optimisation would be a major consideration at the beginning of any project and planned for accordingly. Realistically due to tight deadlines and more functional concerns it’s often a task carried out in retrospect. Either way performance optimisation for your SharePoint site should be considered a crucial task and one that is always undertaken – this article will approach the topic from a retrospective viewpoint.

Part 1 of this series will focus on some of the first steps you should undertake or consider when embarking on performance optimising your SharePoint site. Performance Optimising SharePoint Sites – Part 2 will explore some of the platform-independent techniques available at your disposal while Performance Optimising SharePoint Sites – Part 3 will identify some of the SharePoint-specific techniques able to be leveraged.

Understand the importance of Performance Optimisation

There is a strong correlation between page load times and the success of a website. There is plenty of anecdotal and statistically-backed evidence littered throughout the net to prove this. For a few examples take a look at How Loading Time Affects Your Bottom Line, how Amazon increased revenue for every 100ms of improvement and how ShopZilla increased revenue and page views by reducing load time. Page load times have also been known to influence bounce rates and improve traffic as testified by Google’s Marissa Mayer in Speed Wins. It should be obvious, but with evidence to back it up the likelihood of being granted the time and money to perform optimising tasks should improve.

Establish Benchmarks

In my opinion an important step to undertake before beginning work on optimising a SharePoint website is to establish the performance benchmarks for the site and ideally have a performance target in mind. This works on 2 levels; firstly, having an understanding of the current traffic levels of the site is important. The ultimate goal of performance optimisation is to increase traffic, improve the amount of time spent on the site and if applicable increase conversions. Using a free tool such as Google Analytics may give you the information you need or you can explore a raft of paid options which exist. Secondly you need to capture the current performance of the website. There are a couple of free tools available to do this including Web Page Test and Page Speed Online. With these pieces of information in hand you will be able to accurately determine if the work carried out has had a meaningful influence on both the performance and effectiveness of your site and will increase the likelihood of being able to carry out these tasks in the future.

Know the Tools at your Disposal

There are a number of tools out there that either help identify the areas in which performance optimisation can be implemented, help perform the optimisation tasks themselves or offer somewhat of a shortcut to having to dedicate hours of time on performance optimisation at all. The performance benchmarking tools mentioned above not only rate and measure performance but also offer advice on how your pages can be improved. Tools such as ySlow and Fiddler give you a more granular view of what’s going on as your page loads and with a bit of knowledge lets you target areas for improvement. If you’re hosting your site on SharePoint 2010 then you can make use of the Developer Dashboard to analyse the performance of your page. Products such as Aptimize exist which was famously used on Microsoft’s SharePoint.com to improve performance. Finally, Content Delivery Networks can be leveraged to greatly improve international load times of your site (in my personal experience it was Akamai’s CDN that proved the silver bullet for meeting performance targets on westernaustralia.com).

In Performance Optimising SharePoint Sites – Part 2 of this series i’ll explore some of the platform-independent techniques available at your disposal.

Referencing resources in SharePoint: File system or content database?

Recently I’ve gone through a particular project and modified the solution structure and philosophy behind deploying resources for use within a number of public facing SharePoint sites. It’s a concept I actually hadn’t given too much thought to in the past – previously the majority of projects I’ve worked on or created have simply deployed all resources to the /_layouts/ folder and that was that. There are varying reasons why you would choose one method over the other and a discussion on these will form the basis for this post.

First though a bit of background on what brought this topic to the fore. The project I was analysing was a shared solution used for a large number of public facing websites (5+) hosted on the MOSS platform. All resources (CSS, Images, JavaScript, Flash) were deployed to the 12 hive within a folder structure suitable for identifying the site the resources belonged to. There were some smarts in the code which determined where to reference the resources in question.

The problem was 3-fold. Firstly, some site owners wanted the ability to make changes to the CSS or images themselves and didn’t have access to the servers to do so. Secondly, even if the changes were to be made by the development team they still needed to be done within the weekly change window to deploy the new solution. Finally, because the solution was shared between a number of sites and contained code as well as resources, any minor changes made to an image or CSS file would need to go through a complete and rigorous UAT and regression testing phase before they could be deployed.

The solution was obvious; the resources needed to be stored in the content database, and there are a number of benefits gained from storing resources for SharePoint in there.

  1. Site owners can be given the ability to make modifications to the images and CSS files if desired. Assuming they don’t have access to the server itself, and they shouldn’t, getting the files into the content database is the best way to enable this.
  2. Immediate access. Assuming you’re deploying your resources to the file system via a solution package (and there should be no other option), you’ll require the solution to be deployed and in many cases this needs to be scheduled during a deployment window.
  3. Versioning. Storing these files within the content database will be able to leverage the in-built versioning capabilities of SharePoint assuming they’re enabled. This could be countered with the fact that source control could be considered a form of file versioning.
  4. Backups. This in my opinion is somewhat of a minor benefit as any decent disaster recovery plan would incorporate multiple forms of backup which would include source control and the SharePoint server (assuming virtual environments), however having the files in the content database enables the resources to be backed up both via SharePoint mechanisms and via backups of the SQL database.
  5. Isolation. By storing the files within the content database you’re ensuring that any changes made are far less likely to affect other sites hosted on the same server. Storing the files within separate sub-folders on the file system mitigates this to an extent, but it’s less safe.
  6. Sandboxed solutions. While not relevant to my own situation in MOSS, deploying the resources to the content database enables the solution to be deployed as a sandboxed solution, opening the door to deploying in a hosted environment.

So why would anyone want to deploy their resources to the file system in the first place? I’m going to start by being cynical – developer laziness. Frankly, with tools such as WSPBuilder in 2007 or the build-in developer tools in 2010 it’s simply easier to place your resources into a mapped folder in your solution rather than creating the feature and module to deploy the files to the content database. There are however legitimate reasons why you may want to go down this path.

  1. Global access. It is possible that some of the resources you are deploying need to be used across sites for the purpose of common branding. By deploying to the file system all sites will have access to the files without having to duplicate content into the individual content databases.
  2. Restricting access. While the granular security in SharePoint allows you to lock down access quite significantly, there is the possibility that a user may have levels of access which would give them the ability to modify these resources when they shouldn’t. It would be a bad security scheme that enabled this, but keeping the files out of the content database and on the file system would ensure this never happened.
  3. Performance. Out of the box you’d get better performance having the resources on the file system rather than the content database. You can get around this for the most part using the build-in caching mechanisms within SharePoint such as BLOB caching, however for MOSS at least there are known issues associated with this noted in Chris O’Brien’s post on Optimization, BLOB caching and HTTP 304s.

It’s a question that seems to polarise the SharePoint community and there are a bunch of blog posts, MSDN articles and discussions on this very subject matter. My personal opinion now, which would appear to be backed by a number of credible posts I’ve since read, is that ideally resources for SharePoint should be stored in the content database whenever possible.