Single huge .css file vs. multiple smaller specific .css files?

Question

Is there any advantage to having a single monster .css file that contains style elements that will be used on almost every page?

I'm thinking that for ease of management, I'd like to pull out different types of CSS into a few files, and include every file in my main <link /> is that bad?

I'm thinking this is better

1. positions.css
2. buttons.css
3. tables.css
4. copy.css

vs.

1. site.css

Have you seen any gotchas with doing it one way vs. the other?

Answer 1

I prefer multiple CSS files. That way it is easier to swap "skins" in and out as you desire. The problem with one monolithic file is that it can get out of control and hard to manage. What if you want blue backgrounds but don't want the buttons to change? Just alter your backgrounds file. Etc.

Answer 2

This is a hard one to answer. Both options have their pros and cons in my opinion.

I personally don't love reading through a single HUGE CSS file, and maintaining it is very difficult. On the other hand, splitting it out causes extra http requests which could potentially slow things down.

My opinion would be one of two things.

1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)

2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime.

With either option I would highly recommend caching on the client side in order to further reduce http requests.

EDIT:
I found this blog that shows how to combine CSS at runtime using nothing but code. Worth taking a look at (though I haven't tested it myself yet)

Answer 3

Having only one CSS file is better for the loading-time of your pages, as it means less HTTP requests.

Having several little CSS files means development is easier (at least, I think so : having one CSS file per module of your application makes things easier).

So, there are good reasons in both cases...

A solution that would allow you to get the best of both ideas would be :

• To develop using several small CSS files
  • i.e. easier to develop
• To have a build process for your application, that "combines" those files into one
  • That build process could also minify that big file, btw
  • It obviously means that your application must have some configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
• And to use, in production, only the big file
  • i.e. faster loading pages

There are also some software that do that combining of CSS files at run-time, and not at build-time ; but doing it at run-time means eating a bit more CPU (and obvisouly requires some caching mecanism, to not re-generate the big file too often)

Answer 4

I prefer multiple CSS files during development. Management and debugging is much easier that way. However, I suggest that come deployment time you instead use a CSS minify tool like YUI Compressor which will merge your CSS files into one monolithic file.

Answer 5

The advantage to a single CSS file is transfer efficiency. Each HTTP request means a HTTP header response for each file requested, and that takes bandwidth.

I serve my CSS as a PHP file with the "text/css" mime type in the HTTP header. This way I can have multiple CSS files on the server side and use PHP includes to push them into a single file when requested by the user. Every modern browser receives the .php file with the CSS code and processes it as a .css file.

Answer 6

You can just use one css file for performance and then comment out sections like this:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

etc

Answer 7

You want both worlds.

You want multiple CSS files because your sanity is a terrible thing to waste.

At the same time, it's better to have a single, large file.

The solution is to have some mechanism that combines the multiple files in to a single file.

One example is something like

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

Then, the allcss.css script handle concatenating the files and delivering them.

Ideally, the script would check the mod dates on all the files, create a new composite if any of them change, then returns that composite, and then checks against the If-Modified HTTP headers so as to not send redundant CSS.

This gives you the best of both worlds. Works great for JS as well.

Answer 8

Monolithic stylesheets do offer a lot of benefits (which are described in the other answers), however depending on the overall size of the stylesheet document you could run into problems in IE. IE has a limitation with how many selectors it will read from a single file. The limit is 4096 selectors. If you're monolithic stylesheet will have more than this you will want to split it. This limitation only rears it's ugly head in IE.

This is for all versions of IE.

See Ross Bruniges Blog and MSDN AddRule page.

Answer 9

I typically have a handful of CSS files:

• a "global" css file for resets and global styles
• "module" specific css files for pages that are logically grouped (maybe every page in a checkout wizard or something)
• "page" specific css files for overrides on the page (or, put this in a block on the individual page)

I am not really too concerned with multiple page requests for CSS files. Most people have decent bandwidth and I'm sure there are other optimizations that would have a far greater impact than combining all styles into one monolitic CSS file. The trade-off is between speed and maintainability, and I always lean towards maintainability. The YUI comperssor sounds pretty cool though, I might have to check that out.