Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Single huge .css file vs. multiple smaller specific .css files? [closed]

People also ask

Is it better to have 1 CSS file or multiple?

A site with only a few pages likely only needs one CSS file. Even if it has a few pages with different template, as long as those templates are fairly similar it can be all rolled together. Even sites with hundreds or thousands of pages can often get away with a single CSS file if the pages are largely the same.

Should you split CSS into multiple files?

Summary: You shouldn't organise CSS by splitting it into separate files any more than you should organise a pane of glass by dropping it on a concrete floor.

Is it better to have multiple CSS?

Taking all these factors into consideration, your best bet is probably to have a single global CSS file (including styles used on multiple pages), and if any of your pages use a lot of unique styles, load an extra CSS file in addition to the main one on those pages.

Can I use one CSS file for multiple pages?

Yes, It is possible to include one CSS file in another and it can be done multiple times. Also, import multiple CSS files in the main HTML file or in the main CSS file. It can be done by using @import keyword.


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 build time (runtime minification/combination is a resource pig).

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).

EDIT 2:
I've settled on using separate files in my design time, and a build process to minify and combine. This way I can have separate (manageable) css while I develop and a proper monolithic minified file at runtime. And I still have my static files and less system overhead because I'm not doing compression/minification at runtime.

note: for you shoppers out there, I highly suggest using bundler as part of your build process. Whether you're building from within your IDE, or from a build script, bundler can be executed on Windows via the included exe or can be run on any machine that is already running node.js.


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/


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.


Historically, one of the main advantages x in having a single CSS file is the speed benefit when using HTTP1.1.

However, as of March 2018 over 80% of browsers now support HTTP2 which allows the browser to download multiple resources simultaneously as well as being able to push resources pre-emptively. Having a single CSS file for all pages means a larger than necessary file size. With proper design, I don't see any advantage in doing this other than its easier to code.

The ideal design for HTTP2 for best performance would be:

  • Have a core CSS file which contains common styles used across all pages.
  • Have page specific CSS in a separate file
  • Use HTTP2 push CSS to minimise wait time (a cookie can be used to prevent repeated pushes)
  • Optionally separate above the fold CSS and push this first and load the remaining CSS later (useful for low-bandwidth mobile devices)
  • You could also load remaining CSS for the site or specific pages after the page has loaded if you want to speed up future page loads.

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.php script handles concatenating the files and delivering them.

Ideally, the script would check the mod dates on all the files, creates a new composite if any of them changes, 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.


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)


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.