CODEWITHSUNDEEP
cssperformanceoptimization
nickf
nickf

Reputation: 546503

CSS Performance

Usually when I build a site, I put all the CSS into one file, and all the properties that relate to a set of elements are defined at once. 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've been considering splitting up my definitions into a number of different files (colours.css, layout.css, fonts.css ...) as I have seen recommended. Something like this:

/* 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'd be combining the files and stripping whitespace prior to rollout, so that's not an issue, but my question is: does having all those selectors repeated over and over cause any performance issues in browsers?

Alternatively, are there any tools which avoid this (potential) issue by merging definitions from different files? ie: take the input given in my second example (3 different files), and combine them into one file, like the first example.

Upvotes: 3

Views: 486

Answers (4)

Nathan Long
Nathan Long

Reputation: 126122

I can't comment on performance, but I tried this approach on my website and ended up reverting to one large file.

My reasons:

  • I got tired of creating a rule for div.foo in three or four different files, and opening three or four files if I wanted to change that div.
  • Sometimes it's not as easy as it should be to separate functions. To center a div in IE, you may have to center the text of the parent element, even though that's not the standard way. Now my layout is mixed in with my fonts.
  • As the code grows, the easiest way for me to find things is to do a text search for the element I want. But I have to open several files to see all the rules, and maybe that element doesn't have a rule in this file so I get no matches.

So I went back to having main.css and iehacks.css. And breathed a sigh of relief.

Upvotes: 1

Dan Herbert
Dan Herbert

Reputation: 103547

There shouldn't be any noticeable difference in rendering/parsing speed. As everyone else said, computers are fast enough that they can render CSS pretty quick.

Your problem is really going to be with the number of requests required to load the page. Extra web requests increase overhead when loading a page. It is much faster to load one large file than it is to load several smaller files. It has an impact on both the client (browser) and the server serving up all of those CSS files.

As long as you combine your files in production, you should be fine.

Yahoo's YUI Compressor is a pretty good tool for compressing your CSS files into smaller files. The last time I checked, it can't definitions (at least the last time I looked at it) but there shouldn't be enough of a performance hit to really need to.

Upvotes: 0

anon
anon

Reputation:

As William said, you're not going to see any issue from the browsers parsing the CSS. What you might see, though, is an issue with the number of HTTP requests that a client can open to a single host. Typically this defaults to two. So, if you do put your CSS in multiple files, you might want to put them on a separate sub-domain and they will be treated as a different host which will allow the HTML page to be loaded at the same time as your CSS files.

Upvotes: 0

William
William

Reputation: 6428

The browser will have to find all the definitions and then add them up and override the different properties based on the latest definition. So there will be a slight overhead.

That being said it would be rather minimal and not very noticeable even on hardware 5 years old. The browsers are quite efficient at it these days.

Upvotes: 3

Related Questions