Question

We all know that we’re supposed to combine our CSS into one file, but per site or per page? I’ve found pro’s and cons to both.

Here’s the scenario:

• Large site
• CSS files broken out into one file for global styles and many for modules

Solution A: Combine ALL the CSS files for the whole site into one file:

Best part is that the one file would be cached on every page after the initial hit! The downside is that naming convention for your selectors (classes and id’s) becomes more important as the chance for a namespace collision increases. You also need a system for styling the same module differently on separate pages. This leads to extra selectors in your CSS which is more work for the browser. This can cause problems on mobile devices like the iPad that don’t have as much memory and processing power. If you’re using media queries for responsive design, you’re troubles compound even further as you add in the extra styles.

Solution B: Combine one CSS file per page template:

(By page template I mean one layout, but many different pages, like an article page)
In this scenario, you lose most of the issues with selecting described above, but you also lose some of the cache advantages. The worst part of this technique is that if you have the same styles on 2 different page templates then they’ll be download twice, once for each page! For instance, this would happen with all your global files. 🙁

Summary:

So, as is common in programming, neither solution is perfect, but if anyone has run into this and found an answer I’d love to hear it! Especially, if you know of any techniques that help with the selector issue of Solution A.

Answer 1

Of course, combine and minify all the global styles, like your site template, typography, forms, etc. I would also consider combining the most important and most frequently used module styles into the global stylesheet, certainly the ones that you plan to use on the home page or entry point.

Solution B isn’t a good one: the user ends up downloading the same content for each unique layout/page when you could have just loaded parts of it from the last page’s cache. There is no advantage whatsoever to this method.

For the rest, I would leave them separate (and minified) and just load them individually as needed. You can use any of the preloading techniques described on the Yahoo! Developer network’s "Best Practices for Speeding Up Your Web Site" guide to load the user’s cache beforehand:

Preload Components

By preloading components you can take advantage
of the time the browser is idle and request components (like images,
styles and scripts) you’ll need in the future. This way when the user
visits the next page, you could have most of the components already in
the cache and your page will load much faster for the user. There are actually several types of preloading:

• Unconditional preload – as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a
  sprite image is requested onload. This sprite image is not needed on
  the google.com homepage, but it is needed on the consecutive search
  result page.

• Conditional preload – based on a user action you make an educated guess where the user is headed next and preload accordingly. On
  search.yahoo.com you can see how some extra components are requested
  after you start typing in the input box.

As far as the conflicting selectors go: combining all the files and doing it any other way should not make a difference, this is a problem with your design. If possible, have all modules "namespaced" somehow, perhaps by using a common prefix for classes specific to the module, like blog-header or storefront-title. There is a concept called "Object-oriented CSS" that might reduce the need for lots of redundant CSS and module-specific class names, but this is normally done during the design phase, not something you can "tack on" to an existing project.

Less HTTP requests is better, but you have to take file size into consideration as well as user behavior and activity. The initial download time of the entry page is the most important thing, so you don’t want to bog it down with stuff you won’t use until later. If you really want to crunch the numbers, try a few different things and profile your site with Firebug or Chrome’s developer tools.