CSS Best Practices - Combining All CSS into a Single Stylesheet

css best practices - combining all css into a single stylesheet?

You should combine all your CSS into one file to reduce the amount of requests made to your server.

A similar topic is sprite sheets, the combination of multiple images into one large image to also reduce the amount of requests made to your server.

You'll find that loading 100x 5kb files is a lot slower than loading a single 500kb file.

---

When you're ready to upload your files to a live environment, you should also consider compressing your CSS and JavaScript files. There are a vast amount of online tools for this, eg:

• CSS Compressor.
• JavaScript Compressor.
• HTML Compressor.

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

A CSS compiler like Sass or LESS is a great way to go. That way you'll be able to deliver a single, minimised CSS file for the site (which will be far smaller and faster than a normal single CSS source file), while maintaining the nicest development environment, with everything neatly split into components.

Sass and LESS have the added advantage of variables, nesting and other ways to make CSS easier to write and maintain. Highly, highly recommended. I personally use Sass (SCSS syntax) now, but used LESS previously. Both are great, with similar benefits. Once you've written CSS with a compiler, it's unlikely you'd want to do without one.

http://lesscss.org

http://sass-lang.com

If you don't want to mess around with Ruby, this LESS compiler for Mac is great:

http://incident57.com/less/

Or you could use CodeKit (by the same guys):

http://incident57.com/codekit/

WinLess is a Windows GUI for comipiling LESS

http://winless.org/

Is it good idea to make separate CSS file for each HTML page?

Your example shows you using one design.css file for your entire website.

Generally, it is better to have one single .css file containing data for all pages for 2 reasons:

1. You will allow browsers to cache .css files thus resulting in faster loading times;
2. It will ease the maintenance process.

I would advise you, if you really want to divide .css in separate blocks to use CSS' @import to divide blocks of code f.e form styles and so on.

Multiple CSS files and performance

Merging all of your css files into one will absolutely gain performance. Whether that performance is noticeable depends on your load, number of requests etc. For the average blog, this will have close to zero impact.

Read Best practices for speeding up your web site at Yahoo! Developer. It'll explain things way better than i can.

As you say, a reason not to merge css files is for maintainability. However, there are many tools out there which automatically merge and minify your css files into one.

You should check out YUI Compressor, this will help you with merging and minifing your css files.

One big css file vs multiple small css files

There is pros and cons of both approaches.

Having multiple CSS files will allow you to organize and group your CSS files properly in development. However, this also means that there are multiple HTTP requests to make. HTTP requests are more expensive in terms of loading time as it has to contact the server and fetch the file.

Also once a file is loaded, it is cached by the browser. Which means, even-though it might be initially slower to load the huge.css, it doesn't need to be loaded again when you navigate around the site.

In my experience and adapted by most of the developers, you could do something like below to get most of the both worlds.

Use css pre-processers like SASS or LESS. Don't ask me which one is better, there is already enough arguments going around the web on that topic. Just pick one which you are comfortable with. My preference is SASS.

CSS pre-processers allows you to divide your CSS files into smaller more organized files. For example, you could have a main.sass which includes menu.sass, footer.sass, etc.

main.sass

include _menu
include _footer
include _header
...

_ tells sass not to compile seperate files for each of these sass files. So they all will only be compiled to a one main.css. These pre-processors come with a functionality to compile the given sass files into a css file that browser can read. You can also use tools like [livereload][4] to compile them in real-time.

You will have these sass files in your development code. But in your production code, you can simply use the compiled single css file.

If you are feeling more advantageous and want to take things further, you can use tool like Grunt or Gulp. They allow to automate your development tasks or build processes. So ideally, in development you could have a grunt task that watches all your sass files and automatically compiles them into the main.css file. In your index.html you can have reference to this main.css. Once you are happy, you can also have another task called build task, which can automatically compile all your css files and minimize them.

To clarify your question:

It depends what is best in case by case basis, what kind of site you have and how you have built it.

If you have a website where visitors are most likely to never navigate around the site than some particular pages, then its better to load css specific to that particular page and not combine it. You can load these css files in the partials specific to these page.

In my experience building many many sites,

1. its almost always best to load one combined css.
2. if a particular page requires css is not likely to be visited often, include a page specific css in its templete seperately with a conditional script tag.
3. Minimize all css files almost 100% of time

Also, I will suggest you to spend more time improving efficiency of your server side code or database, then worrying too much about the css. It will be more productive as most of the in-efficiency lies in server side.

How to merge and clean 2 css files with overlapping selectors/properties?

There is This and This list of other helpful tools

Combining CSS files: per site or per page template?

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.

Is it possible to include one CSS file in another?

Yes:

@import url("base.css");

Note:

• The @import rule must precede all other rules (except @charset).
• Additional @import statements require additional server requests. As an alternative, concatenate all CSS into one file to avoid multiple HTTP requests. For example, copy the contents of base.css and special.css into base-special.css and reference only base-special.css.

---

Related Topics