Top 5 Mistakes of Massive CSS
Last week, Stoyan Stefanov and I spoke at Velocity Conference about optimizing massive CSS. We talked about our experiences optimizing large-scale sites like Facebook and Yahoo!, and we discussed our findings regarding the CSS efficiency of the Alexa Top 1000 websites.
Velocity was kind enough to share videos of the session:
What is the state of the internet regarding CSS performance? Kind of sad. We aren’t getting a lot of the basics right, and when we look at the more advanced techniques, there are some spectacular examples of what-not-to-do. Why do we care about CSS performance? As Stoyan talks about in the beginning of the video, it blocks progressive rendering and it is very difficult to auto-minify.
The Basics
These basic rules, made famous by YSlow, have been around for a long time, and yet our data showed that many sites in the Alexa Top 1000 are still not employing the most basic techniques.
- 42% Don’t GZIP CSS
- 44% Have more than 2 CSS external files
- 56% Serve CSS with cookies (yummy to eat, bad for static content)
- 62% Don’t minify (check out the YUI Compressor!)
- 21% Have greater than 100K of CSS
CSS Weight for the Alexa Top 1000 Sites
More Advanced Techniques
I talked about these more advanced tests for the first time at Velocity. Here is how the top 1000 sites stack up and some recommendations for reasonable results.
| Occurrences in one page | ||||
|---|---|---|---|---|
| Declaration | Max | Percentage too many > 10 |
Percentage sites *way* too many > 100 |
Suggestion |
| float | 733 | 56% | 13% | If you have a good nestable grids system, you shouldn’t need many floats. The worst offender in the Alexa Top 1000 sites declared the float property more than 700 times! Aim for less than 10. |
| h1-6 | 511 | 56% | 9% | There are only so many usable font sizes on the web. Below 10px in most fonts is legible only by mice and few sites use really large typography as a design element. Imagine that a site chooses to use 24px as their max. That leaves 14 different sizes, however, we need to divide that number by two because most users can’t see subtle differences like a 1px change in font size. That leaves seven different heading sizes, which means 56% of sites in the Alexa top 1000 have too many heading declarations. |
| margin: 0 | 518 | 64% | 14% | Different browsers have different default stylesheets. These stylesheets define how elements should look if you haven’t chosen an alternate style. It is important to get all browsers to the same starting point because it eliminates bugs and time wasted testing simple browser compatibility issues. This is should be accomplished using a reset stylesheet such as the one included in YUI. When a reset stylesheet isn’t used, margin zero tends to be sprinkled throughout the stylesheet as developers try to cope with browser differences in the absense of an abstracted solution. Setting the default margins to zero is the most basic job of a reset stylesheet, which means that 64% of the Alexa Top 1000 sites could benefit from including reset.css. |
| padding: 0 | 510 | 62% | 10% | Excessive declarations of padding zero are similar to margins (see the above description). The worse offender in this case declared padding zero 510 times. |
| font-size | 889 | 78% | 23% | Headings (h1-6) often get hidden in class names, which can disguise typography efficiency issues. It is helpful to grep "font-size" to get an idea how many hidden headings exist on the site. The same rules apply to font-size that were explained under h1-6, so in fact the problem is much worse than our initial estimate. These figures mean that 78% of the Alexa Top 1000 sites have excessive heading declarations when we consider hidden headings. In addition, 22% of sites may not be getting the SEO benefits of properly using heading elements. |
| !important | 526 | - | 12%* | Important overrides all other declarations specificity, so it can be dangerous. If used correctly, only on leaf nodes, it can be a powerful tool for creating typography and spacing mixins that stand outside of the normal cascade. On the other hand, excessive use of important is a sure indication of specificity wars. Specificity wars are what happens when developers start trying to beat each others specificity, rather than having a real solid architecture and code standards. Eventually, like the worst offender in this case with 526 important properties, you can end up in a case where nearly every property is marked important. This means that 12% of the Alexa Top 1000 Sites probably has an internal specificity war in it’s web team. |
* >50
Happy perf optimizing!
July 1st, 2010 at 6:12 pm
[...] this link: Stubbornella » Blog Archive » Top 5 Mistakes of Massive CSS This entry was posted on Friday, July 2nd, 2010 at 12:18 am and is filed under Uncategorized. [...]
July 1st, 2010 at 10:36 pm
Great talk.
I’m using those OOCSS concepts for quite a while for all new and side projects and it does indeed make sense to create rules which aren’t location specific. Less repetition and predictable results. I really like that.
However, I recently started writing lots of documentation and I used HTML5′s section-tags there in conjunction with H1-tags (and no other headings at all). The big idea (borrowed from XHTML2) is to have some weighting for those headings based on the section nesting.
It’s pretty handy since you can move things around like crazy and you’ll always get a heading with the correct weight. The same effect applies for things like aggregation or overview pages which display excerpts. You never really know where that markup will end up and if you only use section and h1, it will just work fine (at least that’s the theory):
Now, the thing that apparently irks me, are those location specific styles. After all, this kind of thing can’t work without them.
July 2nd, 2010 at 10:39 am
Can you explain the h1-6 one? Not sure I understand. Are we not supposed to use all of h1-6 and many sites do use all of them? Or are some sites using more than the 6 headings? *Confused*
July 2nd, 2010 at 10:40 am
I’m at work and didn’t get to watch your attached video, so please excuse me if it is answered in there.
Also, the rest of the rules are very helpful, thanks!
July 2nd, 2010 at 12:40 pm
@Bryan – definitely watch the video, I think it will make the whole thing clearer. And, check out the slides on slideshare. Basically, if there are only 7 workable font-sizes on a site, it makes no sense to have hundreds of font-size declarations and headings declarations. If we make ten or so that are reusable across the site, we shouldn’t need to keep repeating ourselves! The worst offender defined the heading sizes more than five hundred times and font-size almost 900 times! That’s just crazy.
July 3rd, 2010 at 4:52 am
Well, I prefer the usage of inheritance instead of using classes for styling elements.
In my opinion it’s better to use more classes for elements and IDs for single elements and it’s better to avoid traversing trees with classes – that’s stupid and uses more and more code to do the exactly same thing than the DOM does.
e.g. the definition of:
.abs { position:absolute; left:auto; right:auto; top:auto; bottom:auto; }
.left { left:0px; }
.right{ right:0px; }
.top{ top:0px; }
could be used in that way: …
…and it’s more flexible =)
PS: Have a look at the CSS at http://martens.ms
Greets,
Chris
July 3rd, 2010 at 4:55 am
Well, I forgot to say:
I also avoid using different CSS files for different pages. That’s also stupid – a user with a low bandwith has to look up the nameserver, download the file (if it has no ETags) and the browser has to differ the cache each time the page loads. It’s better to cache everything that will be used surely on the next pages. GZipping it is a good method for low-bandwith-users, but Opera doesn’t support gzipped Stylesheets (it’s a Bug in the cache handler)
July 3rd, 2010 at 11:23 am
[...] – The Top 5 Mistakes of Massive CSS. Nicole (aka, “stubbornella”) wrote a blog post summarizing their work. The motivator for paying attention to CSS are these stats that show how bad [...]
July 5th, 2010 at 12:14 am
[...] I tried posting the link to digg.com, but it just kept rejecting it as spam. If you want to go through it and the video, the link is, http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-massive-css/ [...]
July 5th, 2010 at 5:47 am
So it basically advertises one particular approach. Interesting metrics we have there: number of occurrences.
How about number of classes after those “optimisations” are employed? How about that those classes will litter HTML too, and that’s worse cache-wise?
I’d rather have zero id’s and classes in my HTML.
Reset stylesheets and grids? God forbid.
July 5th, 2010 at 10:26 am
Nice piece. To clarify, in your CSS Weight data, are u using the post-gzip file size when enabled, or pre-gzip? And do you have a recommended target or suggested limit for total CSS weight per page in mind (pre or post gzip)?
July 5th, 2010 at 8:16 pm
맥스제로이쉐뀌의 생각…
Top 5 Mistakes of Massive CSS…
July 6th, 2010 at 1:03 am
Wow, thank you for the video, it’s great
I’m currently taking baby steps around the css/designing world, and trying some solutions to stop having terrible css designed. I’ll definitely give the framework a go
July 6th, 2010 at 12:31 pm
Great talking. So you are the CSS star we are looking for? Dont you?
Thanks for the talking, Good luck.
July 6th, 2010 at 3:33 pm
Great video, nice to see chicks in this business
Just started with css, and while comparing stylesheets to learn from it, everytime i was like why the hack they use exactly the same stuff 4 lines down for exactly the same sort of objects (as you call it duplicates). Kinda mind goggling for a starter. Fun to see i wasn’t alone and there is actually a name for this more logical way of programming OOcss. I was wondering though you mentioned a google group, but i didn’t hear a name. mind telling me?
Love to read your book when it comes out.
cheers!
William
July 7th, 2010 at 5:34 am
Ah I forgot to ask, so here I go; your talking about offenders of floats and that if you have a good grid system you shouldn’t see > 10 floats which sounds logical. Mind if I ask what grid system you could recommend. There are quite a few out there.
And it might help newbies a bit in the right direction. If you have time of course =^.^=
July 7th, 2010 at 6:53 am
Hi Nicole, do you know of any big sites that are using your OOCSS in production right now? Sites that have some various page layout flavors? I watched the video and it is interesting, I’d really like to check some html/css of something more “real world” than “hello world” if you know what I mean. Or, do you have any in-depth demos like a fake site with various page layouts?
Also, it doesn’t look like you’re using OOCSS on your blog, I checked the html/css file and it looks like “standard” type of markup. Not busting your chops, just want to make sure I’m looking at what I think I’m looking at.
July 7th, 2010 at 9:01 pm
[...] Top 5 Mistakes of Massive CSS was one of the top 3 presentations at Velocity . It is interesting to see CSS beginning to get the same kind of attention as JavaScript. [...]
July 8th, 2010 at 2:23 am
“Mind if I ask what grid system you could recommend.”
I would love to know that too.
I’ve tested quite a few, and always have some problems with them (not fluid, grid not usable inside a grid, problems with IE (IE6 but not only) etc.)
July 8th, 2010 at 8:53 am
Enjoyed the video and definitely came away some useful tips that I plan on implementing. I had some questions on a couple of points you made in the video.
1. The ‘media’ block you created for Facebook – when I view my Facebook profile I do not see it in place – all I get is a infested block of HTML. Is this still in development or does it only appear on certain country sites (I’m in Canada)?
2. The CSS reset you use (YUI) – any reason why you chose this over others (i.e. Eric Meyer’s)?
July 8th, 2010 at 11:09 pm
Where can developers learn this information?
I refer to the W3 as the definitive source for html and css. But I also have the following books, “CCS Definitive Guide”, “CSS Mastery”, “CSS in Easy Steps” (I love this little book – doesn’t waste your time), and “Transcending CSS”. I got the most out of the last 2 books for different reasons. But, on page 158, the author says, “For flexibility, I suggest you divide your CSS across three separate style sheets.” I’ve seen that in many places on the Net. The “mistake” of having more than 2 external CSS files doesn’t surprise me. I will definitely checkout “Best Practices for Speeding Up Your Web Site”.
Could you name a couple of quality accessible resources that you believe could benefit developers, so the state of the Internet/CSS performance improves from “kind of sad”.
Thank you.
July 9th, 2010 at 12:02 am
[...] Top 5 Mistakes of Massive CSS What is the state of the internet regarding CSS performance? Kind of sad. We aren’t getting a lot of the basics right, and when we look at the more advanced techniques, there are some spectacular examples of what-not-to-do. Why do we care about CSS performance? As Stoyan talks about in the beginning of the video, it blocks progressive rendering and it is very difficult to auto-minify. (tags: css performance video 2010) [...]
July 9th, 2010 at 7:48 am
Theses stats takes me back when I was working at MySpace. About 2.5 years ago I was brought in to fix the most traffic pages at MySpace. The first thing that we did was applying most of the yahoo’s best practices. As mentioned on your article, most of our CSS problems were important declaration, font declarations and unnecessary floats. We took a huge step by dropping “everything” and creating a CSS system, where most of our developers would “never” have to style anything by just writing semantic markup and adding appropriate classes to elements. Anyways, It’s very refreshing to see someone else trying to fix the same issues that I we had and help the web.
cheers.
July 9th, 2010 at 10:52 am
@Jerome – would it be totally lame if I say my own grids? This is a link to the docs. When you’ve read that, you can click “source” and check out how I’ve implemented them. They allow infinite nesting and stacking, they’re flexible, and the file size is really small.
July 9th, 2010 at 1:25 pm
[...] Inspired by Nicole Sullivan’s blog on Massive CSS and her continuing work on OOCSS, I recently gave a presentation to a number of colleagues at [...]
July 16th, 2010 at 6:04 am
Do you have any examples of sites where Massive CSS (or not-so-massive css) is done right? Reading your stuff and checking out your slides has been enlightening since I have a medium sized site with a ton of distinct pages and a ton of CSS. Looking at some good CSS in practice would be really helpful.
July 16th, 2010 at 8:33 pm
[...] speaking of CSS (in general, no number), the Queen of CSS, Stubbornella, talks about the state (or should I say weight) of CSS around the web. And it doesn’t look good. Like most Americans, a bit on the heavy [...]
July 22nd, 2010 at 12:14 pm
Nicole,
Benoit Goyette has created a Ruby On Rails application for checking the 5 items you have identified. The code source is under MIT License. It can be forked, installed elsewhere. If it can help to start a service for people.
http://lab.pheromone.ca/2010/07/22/cssverificator/
July 22nd, 2010 at 4:56 pm
@karl – Very cool!
July 23rd, 2010 at 7:19 am
Is the 100k means compressed and minified or the uncompressed file?
July 24th, 2010 at 5:27 am
Hi Nicole,
This was in interesting talk.
Can you please clarify the benefits of using classes over IDs?
Personally, I use this criteria
- is this something that it would ever make sense to have more than 1 of on the one page?
If not, I use IDs. So for example, the nav would always be an id. I can understand that it is good to use classes for reoccurring styles, this way you maximize reuse of the css across multiple elements. But if there is only ever going to be one per page, then there can be no reuse.
I like to use IDs for the semantic meaning. IE. ‘This is one of a kind, a fundamental part of my site or a page’ vs ‘This is a generic component that can plug into multiple locations’.
I also suspect that IDs are slightly faster..
Would love to hear your thoughts.
Cheers
July 25th, 2010 at 7:08 pm
Hi Nicole,
This was an interesting talk.
I am curious about why you almost never use IDs.
I personally use the following question to determine if I will use an ID or a Class.
- Would it ever make sense to have more than one of these on a page? (even if there is only one now?)
If I answer no I use an ID. So it would always be #nav.
The specificity is also useful, because whilst it may inherit generic styling, I always want what I define for a unique item to override anything generic.
I also like the semantic meaning. IE “This is one of a kind, a fundamental part of my page/site” as opposed to “This is a reusable doodad that could appear anywhere”.
I also suspect there are (very minor) performance advantages to using IDs over classes.
Why do you avoid them? How do you determine whether to use a class or an ID?
Alistair
August 23rd, 2010 at 1:47 pm
I suspect that the reason behind overusing H1-H6 headings is because of the SEO implementation. That’s why you need to style headings that look differently depending on where they are. What’s your take on that?
August 26th, 2010 at 6:25 am
@Margaret – You might be right about it’s origins (though I suspect it is just inherent in the design of CSS). OTOH, you can achieve the same thing with the h1, .h1{} method, much more cleanly. If you need more than six headings, you can always create reusable classes. Check out content.css: http://github.com/stubbornella/oocss/blob/master/core/content.css#L14-23