CSS performance

Question

Usually, when I create a site, I put all the CSS in one file, and all the properties related to the set of elements are defined immediately. Like this:

#myElement { color: #fff; background-color: #000; padding: 10px; border: 1px solid #ccc; font-size: 14pt; } .myClass { font-size: 12pt; padding: 5px; color: #ee3; } 

I was considering the possibility of splitting my definitions into several different files (colours.css, layout.css, fonts.css ...), as I saw it, it is recommended. Something like that:

 /* colours.css */ #myElement { color: #fff; background-color: #000; border-color: #ccc; } .myClass { color: #ee3; } /* layout.css */ #myElement { padding: 10px; border: 1px solid; } .myClass { padding: 5px; } /* fonts.css */ #myElement { font-size: 14pt; } .myClass { font-size: 12pt; } 

To reduce HTTP requests, I would merge the files and remove the space before deployment, so this is not a problem, but my question is: do all of these selectors really repeat over and over again, causing performance problems in browsers?

Alternatively, are there any tools that avoid this (potential) problem by merging definitions from different files? i.e.: take the input specified in my second example (3 different files) and combine them into one file, as in the first example.

Answer 1

The browser will have to find all the definitions and then add them and override the various properties based on the last definition. Thus, there will be small overhead.

It was said that this will be minimal and not very noticeable even on hardware for 5 years. Browsers are pretty effective these days.

Answer 2

I cannot comment on performance, but I tried this approach on my website and ended up returning to one large file.

My reasons:

• I'm tired of creating a rule for div.foo in three or four different files and opening three or four files if I want to change this div.
• Sometimes it's not as simple as separating functions. To center the div in IE, you may have to center the text of the parent element, although this is not a standard way. Now my layout is mixed with my fonts.
• As the code grows, the easiest way to find things is to do a text search of the item I want. But I have to open several files to see all the rules, and maybe this element does not have a rule in this file, so I do not get matches.

So, I returned to main.css and iehacks.css. And he breathed a sigh of relief.

Answer 3

As William said, you won't see any problem in browsers that parse CSS. However, you can see that the number of HTTP requests that the client can open for a single host. Usually this default value is two. So, if you put your CSS in several files, you can put them in a separate subdomain, and they will be considered as another host that will allow you to load an HTML page at the same time as your CSS files.

Answer 4

There should be no noticeable difference in rendering / parsing speed. Like everyone else, computers are fast enough for them to display CSS quickly.

Your problem will really be related to the number of requests needed to load the page. Additional web requests increase the page overhead. It is much faster to upload one large file than to upload several smaller files. This affects both the client (browser) and the server serving all of these CSS files.

As long as you merge your files during production, you should be fine.

Yahoo YUI Compressor is a pretty good tool for compressing your CSS files into smaller files. The last time I checked, it cannot determine (at least the last time I looked at it), but there should not be enough performance hit that is really needed.