That’s how many CSS files should be loaded on any website.
One
- A one-page site.
- A fairly simple site with just a couple of pages that aren’t too different.
- A blog or blog-like site, where even if there are 1000’s of pages and taxonomies, they look mostly the same.
Two
- A web app with a global set of design patterns, and then lesser-used design patterns on different sections of the site.
- Content heavy site with a global set of structure, grid and typography and then additional CSS loaded for specific sections of site that need more.
- Sites where every page is very unique (global and page-specific CSS).
- Most sites.
Three
- Very complex sites that need global CSS, section-specific CSS, and one-off page CSS
I’m proposing that three is the most CSS files that any page needs.
This is deployed CSS
When I say one, two, or three, I’m talking about CSS files linked to from the head of deployed websites. I’m not talking about the CSS files you edit as a developer. For that, you should work in whatever modular chunks make sense to you. Then those modular chunks get combined into the final set of deployed files. You can do this with things like the Rails Asset Pipeline, using a CSS preprocessor, or with apps like CodeKit.
For instance:
Global = main.css + grid.css + typography.css + buttons.css + print.css
Site section A = tabs.css + editor.css
Site section B = forms.css + video.css + details.css
What gets loaded on “editor” part of site = global.css & site-section-a.css
What gets loaded on “details” part of site = global.css & site-section-b.css
Isn’t one always better?
No. If you are thinking of creating a page-specific CSS file and somehow concatenating the parts it needs into that single file, don’t. It seems like, hey, one request is better than three! But then you aren’t leveraging the browser cache at all.
Let’s say you are in a typical two-stylesheet scenario. As you browse around within a particular section of a site, all those page loads after the first need to load no CSS files at all, as they are already cached. And even jumping into a new section will only need to load one new file (the global is already cached).
If you make a unique CSS file for each page, users will need to request a new stylesheet for each page they visit.
OK
Now you can troll me for oversimplifying things. =)
Totally agree. There’s even no point in separate reset or print CSS files…
Yep, I’d say both those things belong in global. Until the day comes that we can be browsers to only request a print stylesheet when it needs it (upon printing), in which case I’d suggest moving it out to a <link media=”print” …>
Me personally I use one css file for most of my sites, however there have been cases where I have felt the need for 2 or more. It was nice to know what you do, and why you do it the way you do.
Anyways thanks for sharing.
I was just wondering what your suggestions may be when you may be using multiple jQuery plugins, with specific css files associated with them. For example, often I use qTip2, fancybox and jQuery UI and lets even add in a rotator plugin together in a web app.
Would download locally and combine them?
Thanks,
Marty
Yep, leave that file independent, but concatenate it into whatever file needs it (global or section specific or whatever).
Can you elaborate on how you might concatenate them? @import? Less? And would you handle print style sheets the same way?
In theory, this is something I guess we can all agree on. But, WordPressly speaking, how do you manage to fit all these plugin-generated css files in 1 or 2 files, while still keeping maintenance and updates easy ?
Thanks for your answer :-)
I use W3TotalCache for that. It combines all the css files serverside – and you can also do the same for js files (if it doesn’t break your site, that is).
The best thing about W3TC is that you can disable it for logged in users – which helps me with debugging.
My MO as of late has been 3.
1) Bootstrap min
2) Bootstrap responsive min
3) Style.css with all my tweaks.
I could probably get away with combining the first two.
If you are including those on all (or nearly all) pages, then it should be one stylesheet and no more.
you should use the media attribute with responsive bootstrap, so you use 2 stylesheets at all
If I had one single page, I would put the CSS in the document itself and not in a seperate file. No need to go out over the network to fetch something for one single page.
I would discourage this, as you would not be getting the full benefits of caching.
At most, you would only be using the cache for a specific url. When you navigate to a different page, you have to re-download all that CSS again. Having the CSS in an external file (i.e. typical approach) means all that CSS is downloaded once only and cached from then on.
Apologies, I misread/misinterpreted the bit “If I had one single page”.
In that case, yes, that would be a good idea (provided that that single page is in fact cached correctly by the browser – i.e. a static HTML file would be fine, whereas PHP script would require correct settings)
Very good topic Chris and very nice explained.
Ideally one css file is the best way. The idea is to have as fewer server calls as possible in order to load the HTML page as quickly as possible.
One other way to speed up the page loading time is to have as fewer images as possible by grouping css images into image sprites. This way instead of having for example 20 server calls for 20 css images, you can have one single server call for one image sprite .
I think Drupal really has the right approach with this one:
http://cl.ly/3U3l2A2H1Z0a3O3l3x2D
LOL!
On topic though, I wish ResourceLoader (MediaWiki component) was standalone. That would make WordPress, Drupal, and your-own-php-powered-app have a great front-end.
In fairness to Drupal, the css files can very easily be optimized into one file and cached from within the UI. If your Drupal install is live and still has css files not optimized, you’re doing it wrong. I see the site used as an example is now using WP, which also has a similar problem (though I’m sure there’s a similar solution in WP as Drupal has). http://note.io/1uQTt9s :)
By page-specific, do you mean “styles specific to a few very similar pages”? If styles are truly specific to a single page, then they may as well be written to a style element in the head. You save an http request.
If the styles will be used on even one more page, though, you gain cacheability by putting those minimally shared styles in a separate file.
The point is, you need to re-use them enough to warrant the extra http request.
nice post Chris!
Personally I use more css files when i’m developing and join them in a single one when i have to publish.
I completely agree — however, we found out when we tried to compress and merge our CSS on a large client site that IE7 has a filesize limit on stylesheets, beyond which it won’t read the contents. So we’ve had to break our two largest concatenated stylesheets into two smaller files. Very frustrating, especially when you combine with the other IE restrictions:
IE (all versions): Highest number of CSS files loaded by IE is 32 (some sources state even 31). Any CSS file above that limit will be ignored.
IE (all versions): Internet Explorer limits nested @import CSS statements to three from the first linked external stylesheet. source
IE6/IE7: Limit for CSS file size around 285KB (depends on specific stylesheet)
ref: IE CSS Filesize Limit, CSS Size Limit in IE8
Have you seen? http://blesscss.com/
OMG
I realy wasn’t aware of that issue. Shame on you IE! Youre a baad browser.
But it is good to know, that bless is out there (bookmarked). I really hope that I never have to use it.
How do you feel about using embedded CSS on a website that only has one page? I was exploring the HTML of the website for the Humble Indie Bundle and realized that they were using embedded CSS.
Some details:
-The site is only one page.
-The site experiences waves of incredibly high traffic when they release a new bundle, followed by periods of what is probably almost zero traffic.
-Visitors are likely to visit the site once, purchase their bundle, then never return until a new bundle is released.
I was thinking about it, and it seems to me that using embedded CSS in this instance is pretty clever. They are avoiding another HTTP request by embedding the CSS rather than linking to a CSS file.
Thoughts?
I always have one css file for the website in general.
If many pages look similar, I’ll include a second stylesheet for that.
Then if I need page specific styles, I put them in a <style > tag.
Sigh. I live and work in the CMS ghetto, and this post strongly reminds me of that fact. Oh for more control over the sites I work on!
Developers often write plugins/extensions that load stylesheets whether you want them or not. They hardly ever give you an option to forego them. Once in a while, I make a request for this, but I don’t think enough of their users care about it to make it worth their while to implement.
Of course, you can shop around for another plugin to concatenate the stylesheets, but I’ve found it difficult to get one actually working on my Joomla site.
The solution I’ve found is to use Google’s mod_pagespeed for Apache. It doesn’t seem to find and join all the files I want it to, but it helps.
https://developers.google.com/speed/pagespeed/mod
Thanks for letting me whine ;)
I use four.
There is always my single file framework.
And others three: tags.css, ids.css, classes.css
I use this method to separete my stylesheets, works very nice.
–Excuse me about my english grammar.–
WEIRD.
=)
Hah! I’m actually doing all kinds of bad stuff in the opposite direction now that I’ve found that html5 allows it. I make .style. tags in the body first, don’t put them in any external file to start off, and then once I’ve finalize the css to how it want it to be, like after giving it a day or so to stabilize, only then do I move it to a global stylesheet.
Hi Kzqai, I don’t see how that’s bad at all! I do quick and dirty stuff like that all the time, even inline styles, until my “clients” (actually my bosses) agree on what they want. If it’s temporary, and it’s just you working on it, who cares? :)
I work on a lot of sites that have a home page and at most 3 or four sub pages. I tend to put all my CSS into a single file as it forces me to conceive simple reusable design patterns. I’m a reductionist at heart :-)
Aunque estoy de acuerdo con la mayoría de los comentarios expuestos, considero que si deseas desarrollar sistemas es mejor aplicar nivel tres para facilitar el desarrollo de la aplicación a corto y mediano plazo.
Si el objetivo es reducir el tiempo de respuesta existen otros métodos más eficientes de lograr aquello, comenzando con la cache de los archivos base.
While I agree with most of the comments made, I believe that if you want pro systems, level three is best to facilitate application development in the short to medium term.
If the goal is to reduce the response time there are other more efficient methods of accomplishing that, beginning with the cache of the base files.
In your third example, why not include all three stylesheets (global CSS, section-specific CSS, and one-off page CSS) in a single file?
It might seem inefficient at first, but even a thousand extra lines of CSS is only a couple kb. So you just make the person download everything when they first arrive on your site, and then the stylesheet is cached for the rest of their visit.
I can see this approach being problematic for sites with a *huge* amount of traffic where every single kb counts. But for 99% of sites it seems like this would be the speediest and most straight-forward way.
It’s a bit hard to talk about stuff like this abstractly, but I’ll try. In the “three” example above, I’m thinking of sites where the site is so big and there are so many different sections that smushing them all into one stylesheet isn’t practical. Maybe the stylesheet would then be 3MB or something like that (I’ve seen it, more than once). But at least it’s cached then for every page of the site right? Well, maybe. That’s way too big to be cached on mobile, so not there. And that initial hit is so big it’s probably not worth it. By splitting into three, that 3MB isn’t 3MB anymore, it’s so targetted it’s probably WAY smaller. Say 100k, because it’s only loading things it needs, not everything across this giant site. AND it’s leveraging cache better. Global.css is used everywhere and is probably fairly small (good for mobile) and cached. Site-section.css is simliar, and then as people browse around the most they need to download is any (also probably very small) page specific CSS.
You’re totally right. I’m currently working on a project to reduce the number of stylesheets and js files our site pulls in. The number we have now is absolutely ridiculous and I’d like to get it down to about 3 per page. Thanks for posting!
Chris, I see that you’re using an html parser or something like that to allow html in comments, which is something that I happen to have a problem with myself, places where full escaping doesn’t work, and it seems to be a tricky problem to solve.
What solution are you using, and do you recommend it?
hey m sorry if it sounds DUMB !!!
but what if…i have a website, supposedly a blog site with numerous but similar pages and i think about referencing numerous CSS’s…for buttons, media and all other possible styleable elements ???
how would it affect ?????
It amazes me how many web developers over-complicate things, and it takes a blog post like this to go, “Hey, stop over-complicating things and just stick global styles in a single stylesheet.” Good stuff.
I like the simplification you made, however I disagree. I think one is best, but only when it is sent to the client. I believe that you should separate the CSS files according to how it makes the most sense for maintainability according to your situation and then merge them when deploying the site (there are tons of automated merge tools for this). With that said I tend to work on web applications and not websites, so it may be different with a site. I personally separate it similar to what you see below:
reset
print
common css
page specific
user control specific
library specific (jquery, treeview…)
browser specfic
When it is rendered on a page, it is one file, one request. If anyone sees a problem with doing this, please let me know as I would still like to know how I can improve it.
I must overanalyze things. I use one stylesheet on every page, different stylesheets for each section. This is because people accessing different parts of the site I work on probably aren’t going to see other sides of the site. The students are never going to see the teacher’s admin, so they don’t need that stylesheet info, ever. They need a student stylesheet. Both designs share common elements, but rather than stash those commonalities in a “global” css file (which wouldn’t truly be global, just shared between these two users–the public facing site is completely different, yet again!), I just make it an include in Sass and compile it to each sheet.
Sounds smart to me.
99% of my work is in off the shelf CMSs (Drupal, EE, WP). Mostly Drupal & EE. Drupal has a built in setting to combine CSS & javascript files. But for some reason when doing so it usually fails. And let’s be honest, Drupal is known for it’s power and flexibility, not it’s efficiency. The number of browser requests for a single page load is staggering.
When using expression engine though, or rolling my own, I’m a big fan of using HTML5 boilerplate. 1 stylesheet, responsive, mobile first.
I wasn’t aware of the IE selector limit bug. Luckily I don’t think I’ve ever made a site that uses that many selectors.
My approach is to have numerous LESS files (reset, grid, mixins, layout, nav, header, footer, typography, homepage, …) which separate out my styles in logical files so when I need to tweak something I know instantly which file it’s in. Because they’re split up like this, the files are usually pretty small (under 500 lines), so finding the precise style is really quick.
To bring them together I use a single LESS file with @imports, then a custom php file to minify, gzip and cache the output into a single file.
I’m in the midst of building a relatively large site and so far I’ve only got 147 selectors, so I’m doing fine on the IE bug front. I expect there to be quite a lot more when I start skinning it, but I don’t think I’ll be anywhere near the ~4000 of the bug’s threshold.
Laurence,
That sounds so…frickin’…elegant! I am envious of your workflow!
Absolutely agree. Just thought I would point out, this is a great approach for JavaScript files as well. There is no reason to have dozens of JS files loading every page.
The less you load, the faster the site is – the better your SEO is.
I always have a reset css file… so it’s always at least 2 CSS files for me.
Why not include the reset within your “normal” stylesheet? Just wondering why, not being snarky :D I usually keep mine in the main stylesheet.
I call one file like this:
<link rel="stylesheet" href="./style.css?template=page">. Then php compiles everything for that page into one sheet, making only one http request.Usually I go up to 3 but have never gone beyond that.
My structure is usually;
Core Layout (structure)
Styling (typography, gradients, borders etc etc – the main stuff)
Page Specific stuff (for example, to style a slider or unique element).
My resets etc go in the core layout sheet as I like to keep things separate.
Are structure and styling stylesheets used site-wide? How come you don’t combine them? You could keep them seperate in development but combine them for production.
W3TotalCache looks very interesting, looks like every WP site needs that :). I don’t use WP though, and I have solved this ‘problem’ in my template engine. Every template file is able to inject multiple CSS, LESS or JS file in the head section. The server-side script evaluates every file and (re)compiles it if necessary. Then it adds all files to a single cache file. The cache key is unique for every file combination. This way every page has a minimum amount of css but everything is still neatly chopped up in multiple files for developing. The system also has a development mode where all files are embedded separately. (LESS is still compiled obviously).
This makes it easy to build re-usable modules and keep their js/css footprint small.
I realize this is not something everyone can implement. But if you have full control over your server-side code (maybe your own CMS), I can tell you this system has made me very happy ;)
For those that have little experience in programming, have a look at cloudflare.com. I have been testing them this week and it looks great for fixing performance issues. They also offer a system that combines all CSS and JS on existing sites. Might be an option for some.
I would argue the use of a fourth layer for audiences (subscriptions, languages, rights, etc.). Examples: free_trial.css, year_subscription.css, german.css, canadain_fr.css, admin.css, read_only.css
The web is getting faster, browsers are rendering faster and faster. i recently finished a project based on twitter bootstrap. During development i simply included all less and JS files bootstrap has to offer. At the end i cleaned up. But i could not spot any speed difference (ok, i am human). So why the hassle?
Or do you care about the 10KB load you can save here? You might have a look at your images first.
Fantastic as always.
I was quite pleased with myself because I actually knew a limited amount about including multiple stylesheets before this article. Makes a change!
Loving the higher frequency of postings…
Couldn’t agree more with this article – have been employing modular CSS on ecommerce platforms since 2006. The core stylesheet gets served to every page, and then a series of @imports get combined and minified server-side before being injected into the .
Simples :)
Completely agree with you. Full merging CSS is only useful when there are always same css files or all css files are different. In case of partially same CSS files, your approach is the only optimized way to achieve best performance.
Cool post. We at Yandex thinking about this too. We have some prototype of tool that can build CSS (and other static files, i.e. JS) for pages but based on some real statistic about users sessions on site. Thats allow handle situations when structure of site or used blocks changes, so tool can relayout in what combinations blocks styles should be combined to separate bundled files.
Here is link: https://github.com/mihaild/ybundler (unfortunately README only in russian now, but tests and command line help in english).
Hi Chris!
I am also a frontend developer from Yandex.
This is a portal of 100+ services and of course we think a lot about managing our CSS files. Usually we have 1 CSS file per page. But sometimes more. Depending on a project structure a common.css file can appear.
We are able to change our CSS scheme very quickly after analizing which pages of each service are the most popular. This information can influence on a building of our files. It’s all being done automatically because we don’t write pure page CSS but describe our pages declaratively in terms of blocks (different parts of the page). And so we are able to generate as many CSS files as we need in accrod with the cache reasoning.
This is only one benefit of our frontend approach called BEM. If you are interested, you can learn about it with the link http://bem.github.com/bem-method/pages/beginning/beginning.en.html
I will appreciate if you can give me your feedback :-)