One CSS File or Individual CSS Files for Each Page

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.

One CSS File or individual CSS files for each page?

Use a single file, CSS files are cached and therefore reduce the need to download a new file for each new page visited.

To help, I usually slap my CSS through a CSS cleaner to reduce its file size, additionally you can GZip CSS using .htaccess too, making it smaller yet again.

Finally putting all CSS in a single file will make making system wide changes to presentation easier in the future (the entire reason we use CSS in the first place), it will also make debugging easier.

Edit, May 2017

A lot has changed in 7+ years, and anyone looking at this answer should consider researching newer asset delivery methods, especially now use of HTTP2 and preprocessors are more commonplace.

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/

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.

Is it good if I split my CSS file into multiple files for each page?

Ideally you want to abstracts your CSS files into many different SCSS files and then compiles them into one minified master file. One file for the header styling, one for links, one for typography. I was afraid of SCSS but now love it... Nothing changes in production, you are still running off CSS bit in development you are just making your life that little bit more organised.

React one css file or one for each component

It really depends on a lot of things:

  1. How big is your application/website?

  2. Is this going to be worked on by a team or just yourself?

  3. Is this a hobby project or an actual commercial product?

Single file approach

Pros:

  • All styles are in one file, so you just need to look at the one file.

Cons:

  • This file can grow pretty quickly and become a nightmare to maintain.
  • It might become harder to reason with especially if this is worked out by multiple people.

Modular approach

Pros

  • Easy to reason with as the files are split into its own modules.
  • Component modules can be shared (if done right).

Cons:

  • More files to manage in the long run. Although if you have a build pipeline that should be too much of an issue. Webpack, for example, will handle that nicely.
  • Naming all your CSS appropriately (yes naming can be annoying).
  • Might require more initial setup and configuration. (not sure if you're using any build pipelines or tools).


Related Topics



Leave a reply



Submit