When to Split Style Sheets
Published on Mar 5, 2009 (updated Feb 5, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. And if you’re only interested in a robust overview on coding guidelines, check out my little book on it: The Little Book of HTML/CSS Coding Guidelines (updated).
Three factors influence whether it makes sense to split style sheets: probability, meaning (aka semantics), and granularity. Thinking aloud:
Probability has to be considered for all web development decisions. When it’s about splitting up and using separate style sheets, probability is important to e.g. estimate the likelihood of the style sheet to get (too) big, the likelihood of the rules in question to be only temporary, and the likelihood of more people working with the style sheet.
So if you’re dealing with one style sheet but anticipate it to be growing a lot over the next few months, split it up in meaningful chunks. If you’re just adding a couple of rules for testing, don’t split it up. If you’re the only one working with a style sheet, you might be familiar enough with it to deal with a big one.
The meaning of style sheets or style sheet sections is decisive for split-ups as well. It can make sense to e.g. separate a part of a style sheet that just deals with forms, as forms can make up an own “unit of meaning.” It probably doesn’t make much sense to split that form style sheet up into two style sheets, unless it’s so big as to form other meaningful chunks, or includes other, semantically different types of forms.
Also, there’s granularity. You could create a style sheet for every single CSS rule, even rules that just consist of one declaration. That doesn’t make sense because it’s too granular. You could also put all your corporate identity into one big style sheet, saving a couple of HTTP requests and leveraging caching, but understanding and maintaining 15,000 lines of CSS code of which maybe just 200 are relevant for each request make that approach questionable, too.
(It’s all about the thresholds set for these three variables. Give them good thought.)
An example, you might prefer absolute certainty before adding something to your core style sheet, think that all border styles are a good, meaningful thing and should go into another style sheet, and that you don’t mind fine granularity at all. This could suggest that you’re using a main style sheet, have five others defining fonts and whatnot, and even accept Conditional Comments. (The maintenance penalty for these particular decisions can be costly, however.)
The way I usually treat these variables is a mix of not worrying too much about volatile conditions, thus going for standalone style sheets that might have a “test” section in them. I only (but then very much) split style sheets by meaning when otherwise more than 50% of the rules of the overall style sheet would not be needed in there. And overall, I don’t mind large granularity up to, say, 500 different declarations.
I’m taking this approach because I find it more efficient: On the one hand, separating style sheets means more HTTP requests (unless you have a system in place that combines or “builds” them). On the other hand, style sheet size is not decisive for understandability; this largely depends on CSS organization, like reasonable use of modules or comments.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)