One massive CSS - or lots of little ones?

Question

Simple question hopefully.

We have a style sheet that is over 3000 lines long and there is a noticeable lag when the page is rendering as a result.

Here's the question: Is it better to have one massive style sheet that covers everything, or lots of little style sheets that cover different parts of the page? (eg one for layout, one for maybe the drop down menu, one for colours etc?)

This is for performance only, not really 'which is easier'

Answer 1

3,000 lines? You may want to first go in and look for redundancy, unnecessarily-verbose selectors, and other formatting/content issues. You can opt to create a text stylesheet, a colors stylesheet, and a layout stylesheet, but it's likely not going to improve performance. That is generally done to give you more organization. Once you've tightened up your rules, you could also minify it by removing all formatting, which might shave off a little bit more, but likely not much.

Answer 2

Well, if you split those 3k lines into multiple files the overall rendering time won't decrease because

1. All 3000 lines will still need to be parsed
2. Multiple requests are needed to get the CSS files which slows down the whole issue on another level

Answer 3

According to this probably reliable source one file, to satisfy rule 1 (minimize http requests). And don't forget rule 10, minify js and css, especially with a 3000 line monster.

Answer 4

It'll be worse if you split them up because of the overhead of the extra HTTP requests andnew connections for each one (I believe it is Apache's default behaviour to have keep-alive off)

Either way, it all needs to be downloaded and parsed before anything can happen.

Answer 5

The only gain in dividing your CSS would be to download each part in parallel. If you host each CSS on different server, it could in some case gain a bit of speed.

But in most case, having a single 3000 lines of code CSS should be (a bit) faster.

Answer 6

Separating that monster file into smaller once (layout, format and so on) would make development more efficient. Before deployment you should merge and minify them to avoid multiple http requests. Giving the file a new number (style-x.css) for each new deployment will allow you to configure your http server to set an expire date far into the future and by that saving some additional http requests.

Answer 7

I have a site css file that controls the styles for the overall site (layout mainly).

Then I have smaller css files for page specific stuff.

I even sometimes have more than one if I am planning on ripping out an entire section at a later date.

Better to download and parse 2 files at 20kb than 1 file at 200kb.

Update: Besides, isn't this a moot point? It only has to be downloaded once. If the pause is that big a deal, have a 'loading' screen like what GMail has.

Answer 8

3000 lines is not a big deal. If you split them into multiple chunks, it still needs to be downloaded for rendering. the main concern is the file size. i have over 11000 lines in one of our master css file and the size is about 150 kb.

And we gzipped the static contents and the size is drastically reduced to about 20 kb.. and we didnt face any performance issues.

Cheers

Ramesh Vel

Answer 9

It sounds like you are using CSS in a very inefficient way. I usually have a style sheet with between 400 and 700 lines and some of the sites that I have designed are very intricate. I don't think you should ever need more than 1500 lines, ever.

3000 lines of code is far to many to maintain properly. My advice would be to find things that share the same properties and make them sub-categories. For example, if you want to have one font throughout the page, define it once in the body and forget about it. If you need multiple fonts or multiple backgrounds you can put a div font1 and wrap anything that needs that font style with that div.

Always keep CSS in one file, unless you have completely different styles on each page.

Answer 10

the effort of loading multiple css files stands against the complexity (and hence speed) of parsing as well as maintenance aspects

If certain subsets of the monster file can be related to certain html pages (and only those certain pages) then a separation into smaller units would make sense.

example:

you have a family homepage and your all.css contains all the formats for your own range of pages, your spouse's, your kids' and your pet's pages - all together 3000 lines.

./my/*.html     call ./css/all.css
./spouse/*.html call ./css/all.css
./kid/*.html    call ./css/all.css
./pet/*.html    call ./css/all.css

in this case it's rather easy to migrate to

./my/*.html     call ./css/my.css
./spouse/*.html call ./css/spouse.css
./kid/*.html    call ./css/kid.css
./pet/*.html    call ./css/pet.css

better to maintain, easier to transfer responsibilities, better to protect yourself from lousy code crunchers :-)

If all (or most) of your pages are sooo complex that they absolutely need the majority of the 3000 lines, then don't split. You may consider to check for "overcoding"

Good luck MikeD

Answer 11

Check out the Yahoo performance rules. They are backed by lots of empirical research.

Rule #1 is minimize HTTP requests (don't split the file--you could for maintenance purposes but for performance you should concat them back together as part of a build process). #5 is place CSS references at the top (in < head>). You can also use the YUI compressor to reduce the file size of CSS by stripping whitespace etc.

More stuff (CDNs, gzipping, cache-control, etc.) in the rules.