CSS Files in _Layouts or Document Library?

Question

There's been a lively conversation (such as it can be in 140 chars) lately about whether it is better to put CSS files on the disk in the _layouts folder or to store them in a Document Library in the Site Collection. This seemed like a good place to post the topic to allow some longer discussion about it.

As for me, I always prefer to avoid putting anything on the disk if I can avoid it. I prefer a Document Library for the CSS. There are many reasons for this, but here are some: versioning, fine-grained permissions, approval processes, they are a part of a Site Collection backup, touching the server can lead to problems, etc. I also don't believe that files on the disk will be served up any faster than files in SQL if SQL is managed correctly.

What's your opinion? Weigh in!

Answer 1

At a high level, it often depends on your view of the function of the files:

• site 'infrastructure' which is critical to branding (e.g. public-facing WCM). Here you might choose to store on the filesystem as users/content authors will never be modifying the files
• content specific to an individual site, open to customization (e.g. a team site in a collab portal). Here you might store in a library as power users most definitely will want access to these files.

A note on performance - BLOB caching is generally required to get equivalent performance from document libraries and the filesystem - there's more to it than just SQL. Last year I did some optimization work for a public-facing airline site with poor performance, and I found that a big factor was CSS/JS files coming from the Style Library. The issue turned out to be a bug in SharePoint's BLOB cache framework which meant the files were being served with incorrect headers, meaning a HTTP 304 roundtrip occurred needlessly for every file before it was served from the browser cache. The details of this are in my posts:

• Optimization, BLOB caching and HTTP 304s
• More on optimization, HTTP 304s etc. – a solution?

The conclusion to all this was that it is possible to get good performance from files stored in such document libraries, but there are a couple of hoops to jump through first. Maxime documented these in BlobCache, Style Library, and anonymous users

Answer 2

I posted this exact question a few years ago and got 2 detailed responses back, one being from Andrew Connell! Both responses were of similar view point.

Andrew said:

Anthony- The way I do it is all content goes in one of the three special libraries in each site (Images/Documents/Pages) and all branding stuff goes inside the Style Library. I am against putting files on the server in the LAYOUTS folder or anything inside the 12 folder. Ideally, use a Feature to provision these files into the Style Library just as you do with master pages and such. The Style Library is for branding files (CSS, images).
-AC

The other response I received was from Jason Huh : http://www.jyhuh.com/blog"

Jason said :

Both approaches will work, but I think deploying to "Styles Library" and "SiteCollectionImages" (or Content Database with "ghostableInLibrary" mode) make more sense than to TEMPLATE\LAYOUTS... folder (or unghosted in file system). Deciding the location of images might be a big deal, but it is a big deal for the location of style sheets because you have to think about updating style sheets after deployment. There are couple of benefits of deploying to SharePoint Content Database with ghostable mode over deploying to the file system under LAYOUTS.

1. Deploying to Content Database supports versioning. You will be able to update style sheet, xslt, master page, etc. from SharePoint UI or SharePoint designer, keep different versions and roll back to previous state easily.
2. Fewer issues with SharePoint blob caching. Depending on folder locations inside LAYOUTS, files deployed to LAYOUTS folder may not work with SharePoint blob caching, and this might result in annoying glitches. You would not experience this symptom if files are to use out-of-the-box Master Page gallery, Styles Library, SiteCollectionImages, etc.
3. Less footprint. Files deployed to LAYOUTS folder will be available to all SharePoint web applications in the farm including SharePoint central admin, MySite, SharePoint Service Provider, etc. This is typically not what you would expect. Deploying to SharePoint Content Database will make sure that the footprint of files will be limited to a specific FEATURES folder and a Content Database.

Hope this helps. Anthony

Answer 3

Looks like someone already posted my $.02 :)

I don't like them in _layouts... I prefer them in the Style Library. Want my long winded response? Read my article on MSDN: http://msdn.microsoft.com/en-us/library/dd221375.aspx

Answer 4

Another reason to let your CSS files, JavaScripts, images etc stay in the Style Library, Site Assets or other document library is Sandboxed Solutions in SharePoint 2010. If you plan or even thinks of moving your solution to a user code solution then the file system is a no go.

Answer 5

They should be in a site collection so that css designers can change them without having to go through a system modification process with the server admins. Even though the files cannot hurt anything, typical sys mod procedures require multiple approvals and scheduling which is excessive and unnecessary for style sheet changes.

Answer 6

The only problem I perceive is that what happens in the approach where you deploy the CSS via a feature into Style Library (or somewhere in content) is that it puts v1.0 up there.

Designers then short cut this and just use SharePoint Designer and edit them directly breaking the inheritance to the artifact deployed to the SharePoint Root (file system) RATHER than going back and editing the CSS in the feature and upgrading the Solution Package in source control.

This is mainly due to the effort involved for a Designer to use Visual Studio and relying on admins. This does get easier now with F5 in Visual Studio if they can work locally and then finally send it to the admins to deploy to the UAT/Prod farms. They can also, as @wictor pointed out, deploy this themselves as a sandboxed solution if they like too. Again, to do the F5 they need a local, be great if F5 would push to UAT etc.

I tend to push the WSP route for performance and the fact that more often than not when you do CSS stuff you are also deploying other bits like Master Pages, Page Layouts that are all dependent on each other and should be deployed the same way.

Answer 7

I've always put my javascript and css files in a document library where they can be called relatively from a script. The only reason I would say putting them in the _layouts folder is if you plan on implementing the css files into more than one site collection.

Why bother? If the styling for CSS is going to stay with the site collection, it's more logical to have it close to the site collection in the database, rather seperate on a VD. When the site collection gets backed up, so does the CSS/scripting. Makes sense.

Answer 8

I'll weigh in on this as others have so just restating what some others have posted and why.

For years I've been using the StyleLibrary. The reasons to me are obvious and simple:

• The StyleLibrary document library is there, out-of-the-box and in every site (except blank sites)
• It let's me create one per site collection so I can use different javascript/css/content files individually. While this might seem like duplication (and it can be) most times each site collection has a unique look or set of requirements.
• I can deploy files from a solution just by mapping the files to the root /StyleLibrary and not worry about copying files
• Content is versioned so I can do post-deploy edits to things like CSS files or even JavaScript while testing on the "real" site (which if I do anything I can just copy it back into my solution). The versioning is good because I can make CSS edits that only admins can see before I release it to the world
• I don't have to worry about keeping files sync'd across multiple web front ends
• All the files can be opened up in SharePoint Designer so I don't need to grant file level access for example to a web designer (not that I would)

While the _layouts option does make it available to all sites if I really need that I'll look at doing it using a solution deploy. StyleLibrary just let's me do very fluid deployments, be able to edit content/styles/script post-deploy, and lets me work faster and easier than having to take out an entire site just to deploy a new CSS change or a script fix.

Answer 9

I've stored CSS in the Style Library for many implementations and have not had load time problems. I find it better than storing on the file system for several reasons:

1. The library is version controlled, with a check-in/out process and rollback. The file system has none of these.
2. The library is content, which gets distributed across all web heads. The file system requires deployment to all web heads separately, which can cause problems with versioning if, say, you forget to deploy to one of your 4 web heads. Maintenance, especially with a consulting client, is easier with a library because of this.
3. You can view the library and edit the CSS within SharePoint Designer. You cannot view the _layouts directory in SPD.
4. The library allows you to work from your local box in SharePoint Designer, whereas the file system requires you to remote into the server.

I will explore the Chris O'Brien's point about the BLOB caching and 304s to make sure performance cannot be improved, but like I said, I've not noticed any performance hits attributable to CSS storage in a document library.

Answer 10

My personal preference is to store this type of asset on disk since it typically forms part of the solution as a whole, which includes binary assemblies, web part registration config etc. and doesn't typically change in isolation (except to fix layout bugs).

I do agree that there are advantages in storing these assets in the content database though – it makes them simple to edit, version and deploy. With an out of the box SharePoint configuration you are however going to suffer performance penalties, both from the perspective of database server load and network time due to cache configuration issues.

In addition to accelerating page load times generally, Aptimize solves all problems mentioned in this thread (including the 304 issue that Chris refers to) – database load and network time are reduced by intelligent server and client caching, and content changes are automatically picked up by the browser without having to wait for the cache expiry duration. Developers can keep source assets in the content database and push changes easily, and browsers of the site will only ever request these assets again when they have actually changed.

Derek. CTO, Aptimize

Answer 11

There are some differences between the file system (_layouts) and libraries from a caching perspective. Chris O'Brien has a good article that touches on these - Optimization, BLOB caching and HTTP 304s.

Answer 12

I have found it easiest to keep my custom site logos, favicon, and custom CSS externally on a test server for our public facing websites. That way I can just use an absolute URL to these items where needed, and I only have to go to one place to update them.

For example, after a quick update to the CSS file I just have to save it in one place, rather than re-deploying to the various Style Libraries. I don't like to access the SharePoint server unless I absolutely need to, I'm superstitious that way.

We don't do any custom coding, so this has been the best solution for us so far.

Answer 13

When developing from Visual Studio I belive that putting the files in the file system always is the best solution when possible. It is much faster and easier to update and the performance is much better than picking it up from the SharePoint DB.

Also when branding a corporate site, no matter if it's a public facing site or an intranet, the company has spent a lot of money to make sure that their corporate identity shall be intact and therefore these files should not be changed by anyone except for these people who has the knowledge and skills to actually do so. Putting them in the style library, image library and so on often gives the wrong people the power to do more harm than good by changing design from a personal point of view and not from the identity that the company wants to be spread around the world and inside the walls of their corporate senses.

I agree that sometimes the end user wants to have changes in the design in some places but then I vote for having a number of sets with ready made styles that the user can choose from.

Also from a deployment perspectiv, what happens to these files in the style library that has been changed and we want to do a redeploy of the design? Either they stay intact and the redeploy will not have an inpact or the will be overwritten and the changes that has been made will be gone.

Love reading about all this btw .. great posts !! .. :)

Answer 14

In general I have had a lot of luck storing them in doc libs. So far I have not seen any issues with loading and the sites work fine. Most of the work I have done has led me down that path and it seems to be working well. Other's have already gone over most of the pros and cons and I have to agree!

Answer 15

Just about to deploy a SP 2010 instance and it was a good read. But i think i would put the images in the Layouts page and the scripting and css files in a sharepoint library. 1) Images won't be updating much.So goes to a file system 2) Scripting,css etc would be in a SP library and it would be easy to modify and save using SP designer.

What do you guys think?

Answer 16

in most cases for the single site collection i store the CSS, images and JS in a sub folder in style library. If your should be able to use SPD to work with this kind of files it's a good way and you have versioning and permissions regarding to this. In other cases if this files should be at the webapp level and if the CSS file are a part of a branding VS solution and other kind of stuff are provisioning to the filesystem I think the CSS should follow the same pattern. It could also be a question for the customer, should this be handle as an alternative CSS and the customer should be able to update the CSS the filesystem is maybe not the best solution to those who have not access to the server. / C